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READ THIS FIRST 


This issue has several articles that should be of inter¬ 
est to everyone. Carl Mickelson has written a wrapup article 
on the BRU sorting problem that he has described in the past. 
A must article for everyone who uses BRU. 

Ralph Stammerjohn has written the first of what will 
hopefully be a continuing stream of articles. First, is a 
dictionary of over 300 words, phrases, and acronyms related 
to RSX/IAS. Second, is an article describing the SYSGEN phi¬ 
losophy at Monsanto. If you must SYSGEN more than one system 
read this article carefully. Perhaps most important are some 
of Ralph's patches; included are patches that can recover up 
to 1400(8) bytes of pool . 


From the Editor 


I would like to personally thank Ralph Stammerjohn for 
the fine Job he did as the editor of the MULTITASKER. 1 
didn't realize how much work was involved in putting an issue 
together until I started putting this issue together (which 
explains why it is so long in coming). 

The Anaheim Symposia is history. For those of you who 
were unable to attend the biggest announcement was that DECUS 
is going to have a subscription fee. Effective July 1, 1983 
if you want to receive any newsletters you will have to pay 
for them. This fee has become necessary due to the dynamic 
growth rate of DECUS and inflation. The subscription fee has 
not been set as of yet, but we should be informed around 
March 1. DECUSCOPE will not be affected by the subscription 
fee. The only known fact at this time is that there will be 
a subscription fee, exactly what the fee will be or what it 
will include are not known for sure. 

Since we will all be charged for the priviledge of re¬ 
ceiving the MULTITASKER it is my intention to provide an 
issue every month of the highest possible quality. In order 
to provide this I need articles to publish and these articles 


2 


1 



















corn® from you the readers. An article can be on any subject, 
even IAS, of any level of expertise. A large majority of our 
audience are new users. They need articles that many of us 
might consider everyday or simple. Articles should prefer¬ 
ably be in machine readable format (tape or floppy) or of a 
publishable quality on 8 1/2 by 11 plain white paper. 

Charles Goodpasture 

Multi-Tasker Editor 

Phone: (713) 871-8000 


DECUS/RSX SIG Library News 

Paul T ompkin s 
Library News Editor 

Over the years, OECUS, through the DECUS Iibrary, and 
the RSX-ll/IAS SIG, through the SIG tapes, have accumulated a 
huge set of useful software. If you have news about any of 
this software, please send to the Multi-Tasker c/o this co¬ 
lumn. This includes any problems discovered, patches to ex¬ 
isting software, short notes on library submissions you found 
useful, or any other information you may have. Send submis¬ 
sions to Multi-Tasker - Library News, c/o DECUS, One Iron 
Way, MR2-3/E55, Marlboro, MA 10752. 


DIR 


David MeBlatt 

The University of Newcastle 

Department of Mathematics, Statistics and Computer Science 
New South Wales, 2308 

I would like,to advise on the following problems with 
DIR" and “RNO", both of which I have found very useful. 


DIR 

When used without the "V" switch DIR should list the la- 
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test versions of a file in the directory. As version numbers 
are not included in the printout, the date and time are the 
only evidence. Sometimes, it seems, DIR gets these wrong. 
Presumably, it is picking up the first occurence in the 
directory(? > . 

DIR will not wildcard on directories so that it 
becomes awkward to get sorted directories of complete vo¬ 
lumes. I have enclosed a cumbersome but effective solution 
to this using a command file, D1RALL.CMD. Basically, it does 
a PIP CO,03★.DIR/LI to get the list of directories on the vo¬ 
lume, then generates and executes a command file called 
DIRALL.TMP, which it finally deletes. Perhaps someone in¬ 
tends to enhance DIR to provide some decent wi Id carding, but 
meanwhile, this may be of use. 


DIRALL.TEC 

@i/en/ zj @i/C0,03*.DIR$/@i/$/ 
hxb hk 

mb@EWDIRALL.TMP$ 

EN$i.ENABLE SUBSTITUTION 

$ 

<;EN$;G*0LI; 

.OPEN NAME.TMP 
.ENABLE DATA 
■$BLANK■ 

= === = = = = = = =:• <DATE>' •<TIME> •=== === 
Directory listing of '$PAK’ 
dir >tx: -lev $ 

.ub sC$ .ua s3$ qa,.k 3c i,$ 3c i3 
$.,zk qb,.xa -1 rr ga 
1 '$bIank ' 

.disable data 
.close 

PIP TX;=NAME.TMP 
PIP NAME.TMP;*/DE 
$ZJ> 

EX$$ 


DIRALL.CMD 

; USE DIR UTILITY TO MAKE A COMPLETE SORTED 

; DIRECTORY OF A DEVICE, ALL UIC'S 

.; DWEB 12-AUG-82 

.ENABLE SUBSTITUTION 

.ENABLE GLOBAL 

.SETS $BLANK " " 

.ASKS $PAK PACK IDENTIFICATION STRING 
.SETS DEALT "DK" 
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.ASKS DEV DEVICE TYPE C'OFALT'J 
.IF DEV = .SETS DEV DFALT 
.ASKS DVN ‘DEV UNIT NUMBER 
.ASKS OUT OUTPUT TO CDEFAULT TI:] 

.IF OUT = .SETS OUT "TI:" 

ASN 'OUT'=TX: 

PIP TX:=DK7:Cl ,23FORMFEED 
MUN6 DK7:C1,23DIRALL,‘DEV 'DVN' : 

@DIRALL.TMP 

PIP DIRALL.TMP;*/DE 

; END OF DIRECTORY LISTING OF ‘DEV'DVN': TO 'OUT 
; LISTING IDENT IS ■$PAK‘ 


RNO 

An awkward prblem with RNO is that linefeeds, by them¬ 
selves, are not included in the count of lines on a page. It 
is sometimes necessary to have a carriage return - linefeed 
pair. This can make literal sections (.lit to .eli) give 
rise to embarassing page overflows. Files transferred from 
other systems (eg. in FLX RT11 format) often have bare li¬ 
nefeeds for multiple blank lines, giving rise to this prob¬ 
lem. It is necessary to either write a filter program or do 
a messy edit run (e.g. with teco and controls visible on a 
VTIOO by -l,3;w> to name.RNO files. 


SYSLOG 


James G. Downward 

KMS Fusion, Inc. 

P.O. Box 1567 
Ann Arbor, MI 48106 

It recently came to my attention that a fatal "BUG" ex¬ 
ists in SYSLOG for RSXllM V4.0 for those users who include 
XDT in their system. Conditional assembly code to handle 
source code only used by XDT was not included in the distri¬ 
bution source. If SYSLOG is run and the user selects QIO ac¬ 
counting, the system will promptly CRASH. The enclosed SLP 
file solves this problem. I apologize for not catching this 
problem sooner. Since we never use XDT on a system which 
runs accounting, I never noticed the problem until a user who 
generated XDT in their system called up to ask why his system 
crashed. 
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To solve the problem (if you use XD3>, rename SYSLOG.MAC 
to SYSLOG.VGN and create the following SLP correction file, 
SYSLOG.SLP. 

SYSLOG.MAC/AU=SYSLOG.VGN 


- 2,2 

IDENT /04.1/ 
-/V4.0 compatible/,, 



JDG4 

Fix bug in 

$10F IN 

intercept add ress 



19-Sep- 

82 would crash 

systems with XDT 


% 

-/QADTB 

:/,.,/; 

JDG4/ 




QADDTB: 

. IFDF 

A$$TRPR$$DER 

; Wi 

th XDT in system 



.WORD 

$I0FIN+12 

; 1, 

I/O COUNT INTERCEPT 

AD- 

DRESS 

.IFF 


; w i 

th no XDT 



.WORD 

$I0FIN 

: 1, 

I/O COUNT INTERCEPT 

AD- 

DRESS 

.ENDC 






/ 


Install SLP and type SLP @SYSL06.SLP. Then proceed to 
use SYSLOG.CMD to rebuild SYSLOG. 


Working Group News 


Elizabeth Bailey 
Working Group News Editor 


BUG in INSTALL for RSX-llM 


Recently Robert Gezelter encountered a bug in INSTALL on 
RSX-llM Versions 3.2 and 4.0. 

The problem was that in certain case a block of the 
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task's header must be written to disk while INSTALL is pro¬ 
cessing COMMON/LIBRARY region references. Unfortunately the 
code in module INSLB which processes the COMMON/LIBRARY 
references uses RO to hold the PCB pointer for the common re¬ 
gion. Subroutine $RDHDR (which is called by INSLB) will des¬ 
troy RO if the current header block is full. This inconsis¬ 
tent handling of RO by $RDHDR is fixed by saving RO upon 
entry to $RDHDR and restoring RO upon exit. 

RSX prints the following error message when this condi¬ 
tion occurs: 


Base mismatch in common block xxxxxx 

The patches for the various versions of RSX-llM are as 
f 0 I lows: 


Version 3.2 

-2,2,/;RLG001/ 

.IDENT /04.1/ 

-39,,/;RLG001/ 

; RLGOOl 09-AUG-82 HX BUG IN $RDHDR WHICH 

; SOMETIMES DESTROYS RO 

-229,229,/jRLGOOl/ 

$RDHDR::M0V R0,-<SP> ; SAVE RO ON THE STACK 

CMP R4, $HDRBF+512. jHEADER BLOCK FULL? 

-244,244,/;RLG001/ 

30$: MOV <SP>+,R0 ; RESTORE RO FROM THE STACK 

RETURN ; RETURN TO CALLER 

/ 


VERSION 4.0 

-2,2/;RLG001/ 

.IDENT /06.1/ 

-47,,/;RLG001/ 

: R. GEZELTER - FIX BUG IN $RDHDR WHICH 

; SOMETIMES DESTROYS RO 

-256,256,/;RLG001/ 

$RDHDR::M0V R0,-(SP) 

CMP R4, $HDRBF+512. 

-271,271,/;RLG001/ 

30$; MOV <SP>+,RO 

RETURN 

/ 

William D. Burton Jr., Chairman of the Unsupported Ver¬ 
sions Working Group, reports that the same bug appears to be 
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in Versions 3.0 and 3.1. The symptoms appear to be either 
"BASE ADDRESS MISMATCH..." or "PARAMETER MISMATCH..." error 
mess ages. 

The correction file for L12,10TINSROT.MAC for RSX-llM 
Versions 3.0 and 3.1 is as follows: 


-2,2,/;RLG001/ 

.IDENT /03A/ 

-37,,/;RLG001/ 

; RLGOOl 09-AUG-82 FIX BUG IN $RDHDR WHICH 

; SOMETIMES DESTROYS RO. 

; (ADAPTED FOR V3.0 AND V3.1> 

-215,215,/jRLGOOl/ 

$RDHDR;:MOV RO,-(SP) 

CMP R4, $HDRBF+512. 

-230,230,/;RLG001/ 

30$: MOV (SP>+,RO 

RETURN 

/ 

The Virtual Disk Working Group met in Anaheim at the RSX 
SIG general working group session. Current active versions 
of the virtual disk packages were discusses. It was decided 
that the primary goal of the group at this time is to conso¬ 
lidate the various features into a complete software package 
with documentation and command files. The code should be 
condition a I i zed for RSX-llM and RSX-11M+ and upgraded to the 
current version level. This package should then be field 
tested by members of the working group. On completion of 
software checkout, the complete package will be submitted to 
the RSX SIG tape and the DECUS library. At that time, the 
working group will address extensions and enhancements to the 
software package. 

Any suggestions or enhancements that you have or would 
like to see implemented should be mailed to the Chairman of 
the Virtual Disk Working Group: 

Mr. Robert Hayes 
Union Carbide Corporation 
P. 0. Box 3500 
Oak Ridge, Tennessee 37830 
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Help Yourself 


Help Yourself 


David DiGiacomo 
He Ip Yourse If Editor 

"Help Yourself" is a place for you to get your tough 
questions answered. Each month, questions from readers will 
be published. If you have a question, send a letter to the 
Multi-Tasker - Help Yourself, c/o DECUS, One Iron Way, 
MR2-3/E55, Marlboro, MA 01752. 

We would also like to publish the answers to questions. 
If you can help someone, contact the Multi-lasker. Your 
answer will be sent directly to the person in need and pub¬ 
lished in the next edition. 


This Month’s Questions 


RT Emu I at 0 r 

We are trying to locate an RT-11 emulator to run under 
RSX-llM V3.2. MINITAB under RSX-llM requires a FPll floating 
point unit since the taskbuilder (RSX-llM SLOTKB) can not 
cope with MINITAB unless FPll is installed. The RT-11 linker 
can, on the other hand, link MINI TAB without a FPll. We are 
aware of RTEM-11 from DEC but are looking for a more economi¬ 
cal solution. 


Friorik Marteinsson, Hus vers I unarinnar, 108 Reykjavik, Ice- 

I and 


Hewlett Packard 3354 

I have a PDP 11/45 running RSX-llD and I am trying to 
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communicate with a Hewlett Packard 3354 laboratory system via 
a direct link. If anyone has successfully done this, please 
contact me at your convenience. 

Randolph P. Brown, U.S. Environmental Protection Agency 
3311 Groh Road, Grosse lie, Michigan 48138 


Fun Programs 

We are new users with a PDP-11/23, RSX-llM V3.2 with 
FORTRAN 4, using 2 RL02 disks. We are non-programmers at a 
branch office and would like to obtain print-outs of some of 
the smaller fun programs that we can install ourselves. 

James R. Lee, Barringer Resouces 
1455 Deming Way, No. 15, Sparks, Nevada, 89431 


Does anyone have generalized REGIS routines to drive a 
VT125 from RSX-llM? 


B. J. Checkowy, Saskatchewan Telecommunications 
2121 Saskatchewan Drive, Regina, Saskatchewan S4P 3Y2 


DQll Driver 

Our new hardware configuration requires that our PDP 
ll//44s interface with up to four full-duplex serial synchro¬ 
nous communications lines simultaneously. Investigations 
into available interface boards have located only one. 
Digital's DQll, that is DMA and operates at the required baus 
rates (7.2 to 56 KBaud). 

Does anyone know of any cost-effective alternatives to 
the DQll interface boards that are DMA and operate in the 7.2 
to 56K Baud range? 

We are utilizing DEC's RSX-llM Version 4.0 operating 
system. The DQ driver software under this operating system 
is strictly half-duplex. Has anyone been able to modify the 
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existing DQ driver software or develop stand-alone software 
that permits the DQM board to be operated in the 
fuI I-dupI ex mode? 


Raylene Pak, Bendix Field Engineering Corporation 
P.O. Box 67, Moffett Field, California, 94035 


Continuous Flow Analyzers 

We are runnig R8X-11M on a POP 11/34 to collect data 
from up to 32 laboratory instruments, either continuous flow 
analyzers or HPLC's. The data collection system is working 
well, but a current problem is the selection of peaks from 
the raw data. The standard DEC laboratory subroutines pack¬ 
age is perfectly adequate for c.f. analyzers, but less than 
satisfactory for the more complex peaks from the HPLC's. 
There are only three peak-picking parameters available, com¬ 
pared with a minimum of ten for most commercial integrators 
and the determination of peak hights and areas is often ina¬ 
dequate. 

I am sure there must be some better PDP-11 compatible 
software available for GC's or HPLC's but I cannot find any 
in the U.K. Do you know of any in the U.S.A., or if any of 
your SIG can help. I would be grateful. 


C.B. Taskis, Beecham Pharmaceuticals 
Clarendon Road, Worthing, West Sussex BN14 8QH 


It’s in the Code 


Jim Preciado 
Column Editor 


FORTRAN IV-Plug V3.0 


D. Scott Campbe I I 
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Par Technology Corporation 
4575 Hilton Parkway, Suite 200 
Colorado Springs, CO. 80907 

The FORTRAN IV Plus compiler has several undocumented 
switches which produce some interesting, but probably not 
very useful, variations on the listing obtained, and on the 
level of compiler optimization. They are used as follows: 

SWITCH EFFECT 

/FI:2 Produces an Internal dump of some sort, 

perhaps the symbol table. Not sure about 
effects other than values for the switch. 

/LI:n ORing 10(8) to the /LI: switch produces a 

dump of the compiler internal data 
structures and pseudo object code. For 
ex /LI:13 will produce the normal listing 
(source -t- p-sections symbols + generated 
macro) as well as the dump. 

/0P:n Alters the level of optimization used by 

the 

compiler. 0 is no optimization, 3 is the 
highest (default). 

Aside from given the curious something to look at, I can 
see very little use for the dumps produced by the two 
switches. However, if you suspect the compiler is making an 
error due to improper optimization, specifying no optimiza¬ 
tion (/0P:0) will allow you to make this determination. 


EDT V2.0 

Mike Kabo 

University of California, Los Angeles 
1000 Veterans Avenue 
Los Angeles, CA. 90024 

For what It's worth, these are just a few lines to in¬ 
form users of EDT V2.0 of an undocumented feature in keypad 
mode which may or may not prove useful. Use of the gold + 
"left arrow" or "right arrow" In keypad mode shifts the 
screen window contents to what appears to be one tab stop (8 
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spaces) to the left or right, respectively. Neither the set 
tab command nor alteration of the hardware tabs seems to have 
any effect on altering this increment. This action only af¬ 
fects the viewing window and not the contents of the file, 
i.e., inclusion of characters either from the keyboard or 
from a buffer are inserted beginning at the true cursor posi¬ 
tion. 


SYSLOGIN and SYSLOGOUT Command Files 

Allen A . Watson 

The Record 
150 River Street 
Hackensack, NJ 07602 

When doing a SYSGEN it is hard to avoid discovering the 
fact that RSX-11M+ V2.0 supports a C1,23SYSL0GIN.CMD file. 
It is not at all obvious, unless you happen to read the MCR 
manual on the BYE command, that it also supports a 
Cl,2]SYSL0G0UT.CMD file. (And who thinks they need to read 
about “BYE?) Basically, if there is a file called 
C1,23SYSLOGOUT.CMD, BYE will execute it before signing you 
off. 

In the MCR manual under HELLO is a sample SYSLOGIN.CMD 
file showing how to make it chain to a user's L0GIN.CMD file. 
We put a command in ours to notify users if they had mail (we 
are using the MAIL program from KMS FUSION currently and ex¬ 
perimenting with the one from the LBL tools package). 

Using a similar concept I created a SYSL0G0UT.CMD file 
that also chains to a user's L0G0UT.CMD file. It also noti¬ 
fies of unread mail. Here is ours: 


.ENABLE SUBSTITUTION 
.ENABLE QUIET 
.TESTDEVICE TI: 

.SETS TI <EXSTRI>C1:23 
.IF TI = "VT" .GOTO BATCH 
MAIL? 

.DISABLE QUIET 

.SETS FILE <L0GDEV>+":"+<L0GUIC>+"L0G0UT.CMD 
.TESTFILE 'FILE" 

.IF <FILERR> = 1 .CHAIN 'FILE'/LO 
BATCH: .EXIT 


I also made the file check to see whether it is a batch 
(virtual) terminal logging out, and if so did nothing. 

When I was testing my LOGOUT.CMD file, I put a PIP /FU 
directory command in it. Lo and behold, after about 10 sec¬ 
onds, both AT and PIP were aborted by BYE just as if they 
were running when I logged off. Yet it did word for a while. 
I figured there must be a timeout parameter somewhere in BYE. 
Found it, called INDTIM. Looked in the task build file, 
C1,243BYEBLE.CMD, and found It is a task build option, set to 
octal 12 seconds by default. I decided a three minute time¬ 
out might provide enough time to do something useful at lo¬ 
gout and so changed it to 264 octal (180 decimal). Rebuilt 
BYE and it work's Just fine. 

There are some other Interesting GBLDEF's there In BY- 
EBLD. Here they are: 


GBLDEF=$USRSB:0 ; ADDR OF USER SUBROUTINE (0=N0T USED) 
6BLDEF=$MALSB:0 ; ADDR OF MAIL NOTIFICATION SUBROUTINE 
; (0*N0T USED) 

GBLDEF=INDTIM:264 ; TIMEOUT FOR INDIRECT (SECONDS) 
GBLDEF=AB0TIM:0 ; TIMEOUT FOR AB0UR3 AST (SECONDS) 

I intend to investigate the code in BYE.MAC to see what 
possible use might be made of the USER SUBROUTINE AND MAIL 
NOTIFICATION SUBROUTINE options, but meanwhile I was wonder¬ 
ing if anyone else has already experimented. Anybody? 


EDITORS NOTE 


When testing the SYSLOGIN.CMD file ensure that there is 
another privileged CRT logined to the system. If you make a 
mistake in the command file and AT aborts your terminal will 
be set SLAVED. Also keep a copy of the command file in 
another UIC so that if you have problems with the file the 
version in [1,23 can be deleted to allow other users to 
login. 
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Hints And Things 


"Hints and Things" is a monthly potpouri of helpful tid¬ 
bits and rumors. Readers are encouraged to submit items to 
this column. Any input about any way to make life easier on 
RSX/IAS is needed. Please beware that items In this column 
have not been checked for accuracy. Send any contributions 
to Multi-Tasker - Hints and Things, c/o DtCUS, One Iron Way, 
MR2-3/E55, Marlboro, MA 01752. 


Preserving Resident Data Common 

Phil Rowland 

Celanese Corporation 
Charlotte, N.C. 

An efficeint way to keek large applications synchronized 
is to keep pointers and flags in a resident data common. A 
resultant problem is how to keep the disk image (nearly) cur¬ 
rent. One way is to update the disk image. But why have a 
resident image. 

This article describes how to periodically, and espe¬ 
cial ly during SHUTUP, update the disk image. This procedure 
does not require creating new files and the updated data will 
be loaded at the next Reboot or Install. 

Create the resident data common image as described in 
the Task Builder manual. Carefully note the first data disk 
block from the map, normally Block Group and is used to In¬ 
stall to properly load the image. This area should not be 
disturbed and is the key to this procedure. 

Create a program which fully describes the common data 
and links to it. Use equivalences for clarity. Include the 
following (FORTRAN) code: 


OPEN (UNIT=dd, NAME=’ C u i c3n ame .t sk' , TYPE='0LD’, 

1 ERR=xxx, F0RM='F0RMATTED‘, SHARED) 

READ (dd,1010) ISKIP LABEL GROUP 

1010 F0RMAT(2(512X) ) !TW0 BLOCKS WORTH 


WRITE (dd,1020) KOM IWRITE COMMON 

1020 FORMAT (adjust for data type and length) 

CLOSE (UNIT=dd) 

Run the progran with some appropriate reschedule inter¬ 
val, possibly one hour. Also include its execution in 
SHUTUP.CMD. 


Tricks with FMS-11 


John P. Hoekstra 
Yasunobu Suginaka 
powell Quiring 


Macatawa Computer Services, Inc. 
1 West Fifth Street 
Ho I I and, MI 49423 


We recently decided to use FMS for a real time 
application. The named fields and shared forms 
seemed useful. There was only one problem, FMS does 
port dynamic (run time) changing of video attributes 
ing, etc.). We require this to alert the user to any 
range parameters. 


display 
features 
not sup- 
(bI ink- 
out of 


The way around this problem that we are using is to de¬ 
fine the fields that will have varying attributes with no 
video attributes and then define a separate dispty only field 
in a blank part of the screen that allows any ASCII char¬ 
acters (we call this field ATTRIB). The trick is that FMS 
only writes the escape sequences for setting the attributes 
of fields so defined. The video terminals associate the es¬ 
cape sequence with the following character stream. So if you 
put out the required escape sequence for setting video attri¬ 
butes to the ATTRIB field any field after the put will be 
displayed on the terminal with the requested attributes set. 
After you have finished writing the fields you will need to 
put the reset attributes escape sequence to the ATTRIB field. 


You can take this idea one step further by storing the 
printable parts of the escape sequence for setting and reset¬ 
ting video attributes in the named data area of each form. 
The application program can then get the field called BLINK 
from the form, add an escape character to the beginning, put 
the resulting string to the field ATTRIB, put out any field 
requiring blinking, get the field called RESET and do the 
same put to ATTRIB. 
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The advantage of this approach is that the task indepen¬ 
dent features of FMS are preserved <ie. change the forms la¬ 
yout without relinking). The disadvantage is that FMS 
doesn't restore them if a screen refress is done. 


CINT$ (Switch to System State) 

Te rry Coombe s 

Logics (Benelux)BV 
VasteI and 12 
3011 BL 

Rotterdam, Nederland 

The size of a privileged task mapped onto the I/O page 
and a 20K RSX-llM executive is limited to 8K words. Very vew 
privileged tasks need to be mapped onto the exec at all times 
during their execution. Indeed, it is desirable that the 
exec be protected from such tasks as much as possible. This 
contribution allows a privileged (PR:0> task to make use of 
the full 32K virtual address space for its own code while re¬ 
taining the ability to map onto executive data structures and 
code whenever necessary. 

The following macro and subroutine exploit the 
"interrupt-enable" feature of the Connect-to-Interrupt direc¬ 
tive to switch the task into system state. Once in system 
state, the task has acces to the I/O page, the executive, and 
4K words of its own code/data, starting at the macro cal I. 
Code executed in system state must obey the rules set out in 
the documentation for the CINT$ system directive. The task 
returns to task state by executing an RTS PC instruction. 

Apart from the need to ensure that support for CINT$ has 
been included during Sysgen, the only prerequisite is an un¬ 
used vector doubleword (preferably) near the top vector area 


in low 

memory. 




.MACRO 

SWSTK,RET, 

,ERR,?LAB 


JSR 

RETURN 

R0,SWSTK 

; ISSURE CONNECT DIRECTIVE 
; DUMMY INTERRUPT SERVICE ROU 

TINE 


.WORD 

ERR 

; ADDRESS OF ERROR PROCESSING 

CODE 


.WORD 

RET 

; CODE ADDR AFTER RETURN TO 


TASK 

STATE 

CLR 

X.DSKRl ) 

; ENSURE NO CALL ON DISCONNECT 


CALL 

LAB 

; PERFORM USERS'S SYSTEM-STATE 

CODE 

JMP 

@ $DISIN 

; FORCE IMMEDIATE DISCONNECT 

LAB: 

.ENDM 





.MCALL 

CINT$,DIR$,ITBDF$ 


ITBDF$ 




.GLOBL 

X.DSI,X.TCB 


CINT : 

CINT$ 

0,0,0,0,0,0 


SWSTK: 

MOV 

R0,CINT+C.INBA 

BASE IS IMMED. AFTER SWSTK 


MOV 

R0,CINT+C.INIS 

SO IS DUMMY INT SERVICE RTN 


ADD 

6,R0 

SKIP ISR AND USER RET ADDR 


MOV 

R0,CINT+C.INDI 

ADDR OF SYSTEM-STATE CODE 


MOV 

$V$$CTR,CINT+C.INVE ; VECTOR IS JUST LEGAL 

10$: 

SUB 

4,CINT+C.INVE 

POINT AT NEXT VECTOR DOWN 


DIR$ 

$CINT 

TRY 10 CONNECT TO IT 
SYSTEM-STATE CODE ALREADY - 




EXECUTED IF SUCCESSFUL 


BCC 

20$ 

BACK TO CALLER IF FINISHED 


CMP 

CINT+C.INVE, 60 

IF NOT, CHECK IF ALL TRIED 


BGT 

10$ 

TRY ANOTHER IF NOT 


TST 

-(RO) 

SKIP OVER SUCCESS RE1 ADDR 

20: 

MOV 

-<R0) 

GET SUCCESS/ERROR RET ADDR 


RTS 

RO 



Swedish Pascal under RSX V4 

Seved Torstendahl 

Telefon AB LM Ericsson 
S-126 25 Stockholm, Sweden 

The "Swedish Pascal" compiler will not run if built 
under RSX V4. The problem is that the compiler is heavily 
overlaid and that a patch must be applied to the overlay rou¬ 
tine because of the recursive use of procedures in Pascal. 

For RSX V4 the following changes have to be made: 

- modify module RECURS in PASLIB.OLB using the following 
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procedure: 

1. extract RECURSEG.MAC from SRCFIL.PAC using the utility se¬ 
lect or an editor. 


2. apply the 

f 0 1 lowing 

SLP file to it: 


3 

.IDENT 

/RSX.V4/ 


- 17, 

, 17 



; $AUrO+36 := 8R SEGENT 


- 23, 

23 




MOV 

SEGEXIT,14(SP) 

;RSX.V4 

- 28, 

30 




JMP 

$AUT0+42 

;READ SEGMENTS WHEN 

READY 



;C0NTR0L TRANSFERRED 

TO SEGEXIT 




99$: 

JSR 

R4,$WRERR0R 


o 

1 

41 




JSR 

R5,.SAVRl 



MOV 

@ N.0VPT,R1 

;N0RMAL SEGMENT READ 

START 




- 47, 

49 




JMP 

$AUT0+42 


9$: ;; 

MOV 

(SP>+,R2 


/ 





3. assemble: MAC RECURSEG=RECURSEG 

4. modify PASLI8: LBR PASLIB/RP=RECURSEG 

- change patch in PAStIB.CMO fron 34:435 to 36:441 giving 
the line 

GBLPAT=R00T:$AUT0+36;441 ; BR SEGENT 

After these two changes the compiler can be rebuilt 
using TK8 . 


Speak Out 


"Speak Out" is a monthly column for readers to express 
their opinions or to comment on a previous column. The arti¬ 
cles published in this column are an individual's viewpoint 
and do not necessarily reflect the opinion of DECUS or the 


RSX/IAS SIG. Readers are welcome to submit articles on any 
subject concerning the RSX/IAS world. Send submissions to 
Multi-Tasker - Speak Out, c/o DECUS, One Iron Way, MR2-3/E55, 
Marlboro, MA 01752. 


A Further Note on RX03 Problems 


John G. Roth 

University of Toronto Computing Services 
Toronto, Ontario, Canada M5S lAl 

We also use DSD-880 floppy/Winchester on some of our 
systems and are disappointed about DEC’S quiet decision to 
drop double sided support. 1 was also able to patch the DY: 
by comparing V3.2 and V4.0 source, but could not get the sys¬ 
tem to MOUnt double sided diskettes. I compared my patch 
with the patch given by Greg Liverman in the Sept/Oct Multi¬ 
tasker and found it to be the same (except for cosmetic 
differences). 

The key, which Greg mentions with respect to the execu¬ 
tive corruption problem, is in forcing MOUnt to do a sense 
characteristics QIO. (It appears that MOU is trying to read 
a block above the single side limit, in addition to reading 
block 1. MOU detects incorrect volume labels, but returns 
lE.RER errors if you specify the correct label or /0VR.>. 
Not wnating to modify MOU, I wrote a 'one-liner' to do the 
sense and RUN it with a double sided diskette in the drive 
before MOUnting. Thanks to Greg for pointing the way; and 
I've sent DEC and SPR suggesting that MOU be fixed. 


RSX Buzzwords 


Ralph W. Stammerjohn 
Monsanto 

800 N. Lindbe rgh 
St. Louis, Missouri 63167 

The following is a alphabetical list of over 300 words, 
phrases, and acronyms related to RSX/IAS. The Iist covers a 
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wide variety of subjects, from the very basic to executive 
internals. The definitions are given in the RSX/IAS context 
and not as they may globally apply to computers. 

Many RSX terms have acronyms which are their more fami¬ 
liar form. This document has the definition listed under the 
acronyms and points to term to the shorthand description. 

For further information on RSX/IAS concepts and basic 
information, the reader is refered to the Introduction to 
RSX-llM and RSX-llM-Plus (AA-L763A-TC> and the RSX-llM Infor¬ 
mation Directory and Index (AA-2b93F-TC>. These two manuals 
will get you started with the rest of the RSX manual set. 

CO,03 

CO,03 is the notation for the master file directory. 
CO,03 is the directory that has entries for the user di¬ 
rectories. Each user directory shows up as a file with 
the name gggooo.DIR;! - where ggg is the owner number 
and 000 is the group number. For example, directory 
C7,1143 is a file In CO,03 with a name of 007 114.DIR; 1 . 
Other system files are also found in CO,03. These in¬ 
clude the index file <INDEXF.SYS>, disk block bit map 
(BITMAP.SYS ) , bad block file (BADBLK.SYS> , and account 
file (RSXll.SYS). CO,03 does not normally show up in 
wildcard searches, but it can be directly named. 

Abort 

Abort means terminating a task abnormally. This can ei¬ 
ther occur because the task had an unexpected failure 
due to a programming error (SST), another task issues 
the executive directive ABR7$, or a user from a terminal 
explicitly aborts the task. When a task aborts, the 
RSX-llM executive cleans up all the context for the task 


as b 

e s t it can. 

See 

also I/O 

Rundown 

and 

SST. 


Accoun t 








Each 

RSX user is 

identified by 

a pair 

0 f 

oc ta 

1 numbers 

and 

a ASCI I name 

and 

must use 

either 

the 

numb 

er or name 

to g 

ain access to 

the 

system. 

These 

numbers 

and name 

are 

called accounts. 

The two 

octal 

account n 

umbers are 

cal 1 

ed the group 

and 

owner number. Each 

has a 

range of 


1 to 377. 

When you log in, the RSX system program HELLO uses ei¬ 
ther the account number or name to find a record in the 
system account file. This file has a password which 
must match your supplied string and various defaults for 
your session. Your account number informs the system 
what initial directory you want to work from and what 
kind of access to files and other system facilities you 
will have. The account numbers are directly tied into 


the protection mechanisms of RSX. Privileged users 
(those having group numbers equal or less than 10) have 
access to all system commands and all parts of the sys¬ 
tem. Nonpr i Vi I eged users are limited to everyday opera¬ 
tions that do not threaten the integrity of the system. 
See ACNT, File Protection, and Privilege User. 


ACNT 

RSX accounts are kept in a special system file named 
LB;i:0,03RSXll.SYS. ACNT is the RSX system utility for 
defining, deleting, changing, and listing the current 
accounts in this file. 


ACP 

ACP is an acronym for Ancilliary Control Processor. An 
ACP is a privilege RSX task with that is used to imple¬ 
ment protocols for classes of devices. ACP‘s form an 
integral part of the RSX I/O mechanism. Examples of ACP 
tasks include FllACP for the Files-11 disk and MTAACP 
for ANSI labeled magtapes. See I/O mechanism. 


ACS 

ACS is the RSX system utility for defining and removing 
checkpoint files. See Checkpointing. 


Active Task List 
See ATL. 


Address Page Register 
See PAR. 

Ancilliary Control Processor 
See ACP. 

APR 

See PAR. 


ASCII 

ASCII stands for American Standard Code for Information 
Interchange and is the standard coding used in RSX for 
character information. ASCII defines a 128 character 
set, which is stored in a PDP-11 in eight-bit bytes. 


ASECT 

Memory allocation for various code segments when a pro¬ 
gram is linked in established by attributes assigned to 
program sections. ASECl is a special form of the gener¬ 
al program section (PSECT) directive that defines an ab¬ 
solute segment. This tells the task builder that the 
segment cannot be relocated and must be linked starting 
at absolute virtual address zero. See PSECT. 
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AST 


AST is an acronym for Asynchronous System Trap. A sys¬ 
tem trap is a transfer of control that is caused by some 
event. RSX defines two types of system traps, synchro¬ 
nous (SST> and asynchronous (AST). 

An AST is a trap that occurs asynchronous to program ex¬ 
ecution. That is, the program has no direct control 
over the precise time and point the event - and there¬ 
fore the trap - will occur. Examples of AST's include 
I/O completion, mark time expiration, or message sent 
from another task. 

A program specifies AST notification for different types 
of events. When the event actually occurs, the execu¬ 
tive queues the AST to the task. The AST wi I I then in¬ 
terrupt the normal task execution the next time the task 
is scheduled and control will be passed to the AST trap 
address. The executive knows when a task is executing 
an AST and waits until the processing of the AST is com¬ 
plete before initiating another queued AST trap. A pro¬ 
gram can also selectively enable and disable AST notifi¬ 
cation. 

Asynchronous System Trap 
See AST. 

ATL 

ATL stands for Active Task List. The AIL is a 
priority-order list of all tasks actively competing for 
system resources, i.e. in execution. Ihis includes 
tasks which may be checkpointed out of memory. See STD 
and TCB. 

Attach 

Attach has two meanings In RSX. First, attach is an I/O 
function <10.ATT) which grants a program exclusive ac¬ 
cess to a n 0 n-shareabIe device. Once a program success¬ 
fully attaches to a device, only its I/O requests will 
be sent to the device. All requests from other tasks, 
including their attach requests, will remain in the dev¬ 
ice queue. 

Second, attach is a PLAS directive function that allows 
a task to gain access to a region of memory. Once a re¬ 
gion is attached by a task, it can then map windows into 
the region and directly address it. See PLAS. 

Attachment Descriptor 

Attachment Descriptor Is an RSX executive data structure 
stored in pool. It ties tasks to the various regions 
and partitions in memory that they have attached. 
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Autoload 

Autoload is the method of loading overlay segments. In 
which the Overlay Run-Time routines automatically load 
overlay segments when they are needed. The asterisk <*) 
is the control symbol in overlay descriptor files that 
tells the taskbuilder to setup autoload vectors for the 
module. 

AutoloadVectors 

A transfer of control table generated by the Task Build¬ 
er to resolve a overlay reference. When an overlaid 
routine is called, the reference is actually to the au¬ 
toload vector which passes control to the Overlay 
Run-Time routines. These routines do any disk I/O ne¬ 
cessary to bring the routine into memory and then pass 
control to the actual routine. 

Autopatch 

Autopatch is a part of the Software Maintenance Service 
mechanism. On a irregular basis (about three to four 
times a year), Digital makes a machIne-readabIe compila¬ 
tion of all patches that apply to the current release of 
the operating system and many layered products. The 
media is typically magtape. 

Autopatch kits are named alphabetically by their 
occurence: Autopatch A, B, C, and so forth. There is 
master documentation for the entire kit and specific do¬ 
cumentation for each set of patches to layered products. 

The patches supplied by Autopatch usually come in two 
forms; SLP correction files for distribution sources 
and PAT source files for distribution object modules and 
object libraries. The patches are always applied to the 
original distribution, no manner how many Autopatch kits 
may have been distributed in the past. Also, Digital 
has used the Autopatch kits to distributed completely 
new versions of software that did not make the original 
distribution. 

Autopatch kits are historically not entirely bug-free 
and usually do not have a one-for-one relationship to 
the Software Dispatch. 

BAD 

BAD is a RSX system utility for detecting and recording 
the bad blocks on a disk. BAD writes a worst-case pat¬ 
tern to all blocks on a disk and reads the pattern back. 
Any errors detected are stored in the last good block on 
the disk where it is used by the disk Initialization 
program, INI. BAD is also handles disks with last—track 
information. See Bad Block File. 
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Bad Block File 

The bad block file is a RSX system file 
<CO,ODBADBLK.SYS> created when the disk is initialized 
by INI. The file contains all the bad blocks found on 
the disk by the BAD utility or from the manufacturers 
bad block data. Placing the bad blocks into a file 
makes them unavailable for allocation by other files. 

Bitmap 

A bitmap in RSX is a free/used mapping where each bit in 
the set indicates whether a item is in use or free for 
allocation. The bit is set on if the corresponding item 
is free. The mapping within a word is from 
right-to-Ieft, i.e. bit 0 of the first word maps the 
first item, bit 1 maps the second item, and so forth. 

Two examples of bitmaps are the index file bitmap and 
the disk allocation bitmap. The first indicates 
free/used blocks in the index file. The second is for 
block allocation for the entire disk. 


block into memory and start its execution. The Boot 
block code then does the second phase of booting up a 
system. See also Bootstrap, INITL, and SAV. 

Bootstrap 

Bootstrap is the process of completely starting a PDP-11 
with fresh copy of the RSX system. In RSX, this is a 
three step process. First, the hardware ROM bootstrap 
code reads the first block of the disk into memory. 
This block contains code to then read the entire system 
image into memory. Finally, control is passed to the 
system startup code, either INIIL for a virgin system or 
SAV for a saved system. 

BRO 

BRO is the RSX system utility for outputting a message 
to specified terminals, either a single terminal, all 
logged in terminals, or all terminals. It is typically 
used to carry on a conversation between two terminals or 
to notify all users of some change in system status. 


Block 

A block is a unit of measurement for disks. In RSX, a 
block is 256 words (512 bytes) and is the smallest ad¬ 
dressable unit of a disk. 

The term block is also used to refer to an arbitrary 
number of contiguous bytes used to store logically re¬ 
lated information, such as a Unit Control Block (UCB) , 
File Control Block (FCB), or Task Control Block (ICB). 

Blocked Task 

A blocked task is an active task that cannot execute. 
Blocked tasks do not compete for the CPU but do compete 
for memory at their current priority. A task typically 
enters a blocked state by waiting for an event flag as¬ 
sociated with an event to set. Tasks can also be 
blocked by user commands. 

BOO 

BOO is the RSX system utility to bootstrap a named file 
as a system image. The current system context is com¬ 
pletely erased. See Bootstrap. 

Boot Block 

The Boot Block is the first block on a disk. This block 
contains the code necessary to read a system image on 
the disk into memory and start execution of this image. 
The boot block has the starting physical block and 
length of the image to read. Boot blocks are created by 
the SAV program when the /WB switch is used. The PDP-11 
ROM bootstrap loaders have only enough code to read this 


BRU 

BRU is the main RSX system utility for making backups of 
disk volumes and restoring from the backup to a disk. 
BRU is highly optimized for speed and has support for 
various types of incremental backups and selective file 
restores. 

Bucket 

Bucket is the I/O and disk storage unit fore RMS rela¬ 
tive and indexed files. 

BYE 

BYE is the RSX system utility for terminating a terminal 
session. BYE cleans up any current activity from the 
terminal by aborting tasks and marks the terminal logged 
out. Until a correct login sequence is completed, RSX 
will not accept any commands from the terminal after a 
BYE. 

Cache 

Cache refers to a technique of putting a high-speed, 
limited set of objects in front of a bulk storage of the 
objects. All accesses for an object are first checked 
to see if present in the cache, and if so, retrieved 
from it to speed access. The cache will have some al¬ 
gorithm for determining what objects to store and dis¬ 
card (look-ahead, least recently used, fixed). 

On PDP-ll’s, cache is typically used for memory. 
High-speed memory is put in front of main memory on the 
PDP-11/44/60/70. RSX supports the use of cache on those 
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processors. Caching is also sometimes used by operating 
systems for disk blocks, but not currently by RSX sys¬ 
tems . 

Catch-AII 

Catch-All is a MCR mechanism by which it passes any com¬ 
mands with verbs it does not recognize to a task named 
...CA. The catch-all task can then take whatever action 
on the command line it pleases, including constructing 
new commands and passing back to MCR. See CCL. 

CCL 

CCL stands for Concise Command Language and is the most 
popular implementation of a catch-all task for RSX. CCL 
comes from the KMS Fusion kit on the SIG tapes. It is 
table driven and supports option prompting, command 
parsing, and MCR command submission. 

CDA 

CDA is the RSX system utility for outputting formatted, 
annotated I istings of RSX crash dumps. 

Checkpoint!ng 

Checkpointing is part of the process by which RSX makes 
memory space available to tasks. If a tasks is waiting 
to run and no memory is available for It, RSX will move 
any lower priority task from memory to disk to make mem¬ 
ory space available for the task waiting to come into 
memory. Tasks which are moved out of memory will be 
brought back into memory when either a task exits and 
frees up memory space or they can checkpoint out an even 
lower priority task. 

Checkpointing is invisible to the user and task and is 
an automatic process. The typical way you learn the 
checkpointing is occuring is because response time of 
your tasks is slower than normal. 

CL ; 

CL: is a pseudo device that is always present in a RSX 
system. CL: stands for console listing device and is 
typically redirected to the console terminal. See Pseu¬ 
do Device. 

CLI 

CLI stands for Command Line Interpreter. CLI's are a 
RSX system feature and provide the mechanism for a user 
to communicate via a terminal with the operating system. 
Whenever you sign onto a RSX system, a CLI is associated 
with your terminal. The CLI then gets all unsolicited 
input from the terminal and processes it according to 
the command language the CLI provides. The two CLI's 
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provided by Digital are MCR and DCL. 

CIoc k Que ue 

The clock queue is a time-ordered list of future events. 
The queue is kept in the executive pool and includes 
mark time and task scheduling requests has well as 
internal RSX executive timed events. 

ClusterLibrary 

Cluster libraries are two or more resident libraries 
that share the same virtual task address space, i.e. 
the same APR. The overlay control code uses the PLAS 
directives to correctly map the appropriate cluster li¬ 
brary when a routine is called. 

CMP 

CMP is the RSX utility to compare two source files and 
report the differences in a variety of ways. 

CO: 

CO: Is the console output device. If console logging 

is not included in a system, CO: is a pseudo device 

typically directed to the console terminal. Otherwise, 
the CO: device is a real device used as a gateway to 

direct output to the console logging mechanism. 

Command Dispatcher 

The command dispatcher, MCR..., is a special RSX system 
task that takes all unsolicited input from terminals and 
passes to the appropriate CLI for that terminal. See 
Unsolicited Input. 

Command Line Interpreter 
See CLI. 

Command String Interpreter 
See CSI. 

Connect-to-Interrupt 

Connect-to-Interrupt is a feature of the RSX executive 
that allows a privilege program to connect its service 
code to a interrupt vector. This allows special devices 
to be serviced directly from a task without the need to 
write special device drivers. 

Contiguous 

Contiguous means a set of physical adjacent objects, 
typically refering to disk blocks. In a contiguous 
file, the entire block allocation is a set of physically 
adjacent blocks. This means only one operation is need¬ 
ed to map a virtual block to logical block in the file, 
simply adding the starting logical block number to the 
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virtual block number. Because contiguous files are much 
more efficient to handle, RSX requires certain files, 
specifically task images, to be contiguous. 

Control Status Register 
See CSR. 

C o-T re e 

One of one or more secondary tree structures within an 
overlay structure. All modules contained in a co-tree 
are accessible from any point in the main segment or a 
lower co-tree. Conceptually, a co-tree can be consi¬ 
dered has a second, independent overlay structure within 
a task . 

Common Block 

Common block refers to either a Fortran common area or 
is another name for resident common. 


Crash 

A crash is a RSX system's response to an unstable condi¬ 
tion. Mhen the executive encounters a condition it is 
unable to handle, it stores certain volatile information 
on a special crash stack and enters special code to re¬ 
cord all of memory to a scratch media. The system must 
then be bootstrapped to continue normal operations. See 
Crash Dump and COA. 


Crash Dump 

Crash Dump is a copy of alI of physical memory at the 
actual point the system encountered an exception it can¬ 
not handle. Special code in the executive has primitive 
routines for recording memory to various scratch media. 
This copy can be symbolically interpreted by CDA. 


CRF 

CRF is a slaved RSX task for processing cross-reference 
information accumulated by either the Macro assembler or 
task builder and appending a cross-reference listing to 
either the macro listing or task map. 


C ros s-Ref e r enc e 

Cross-Reference is information which shows all occu¬ 
rences of a symbol in either a macro source or task 
build. The Macro assembler and RSX task builder record 
each time a symbol is encountered. This information is 
passed to CRF for actual cross-reference processing. 

CSI 

CSI stands for Command String Interpreter and is a set 
of system library routines used to parse RSX command 
lines. Almost all RSX utilities use CSI for command 


processing, so a consistent interface is provided across 
u ti I (ties. 

CSR 

CSR stands for Control Status Register. Each peripheral 
on a PDP-11 has a set of registers that allow control 
and operation of the device. These registers look like 
memory locations at certain fixed positions. Ihe main 
register for a device is called the CSR by convention 
and is typically, but not always, the first register in 
the set. See I/O Page. 

Dataset Descriptor 

A dataset descriptor is a FCS control block that points 
to the device, UIC, and filename portions of a filename 
string. 

DCB 

DCB stands for Device Control Block. DCB's are the por¬ 
tion of the device databases which defines a class of 
like devices, such as all terminals, all RK05‘s, etc. 
The DCB names the device, has the mapping to the device 
driver, and specifies the legal functions serviced by 
the device driver. 

DCL 

DCL stands for Digital Command Language. DCL has sever¬ 
al levels of definitions. DCL is a Digital standard for 
command languages that is supported across many operat¬ 
ing systems. This provides a consistent user interface 
when moving from RSX to other systems. 

DCL is also the RSX implementation of the standard. It 
is a task that is known to the system as a CL I. The 
command dispatcher, MCR..., passes unsolicited commands 
to DCL for parsing. DCL uses a table-driven mechanism 
to parse the commands and construct actual MCR commands 
to pass back to the command dispatcher for actual execu¬ 
tion. 

DECnet 

DECnet is a layered product for RSX that allows network 
communications to other Digital operating systems. 

Detach 

Detach has two meanings in RSX. First, Detach is an I/O 
function (lO.DET) which releases a program's exclusive 
access to a non-shareabIe device. See Attach 

Second, detach is a PLAS directive function that allows 
a task to release access to a region of memory. 
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Device Control Block 
See DCB. 

Dev ice Driver 

Device Driver is a RSX-11M/M-PI us term for the code 
which actual services a peripheral. Device drivers form 
the bottom of the RSX I/O mechanism and are perform the 
basic I/O functions for the device; read, write, spe¬ 
cial control. Device drivers need not reside inside the 
executive, but are mapped directly from the executive 
and execute in kernel mode. 

Device Handler 

Device Handler is a RSX-llD/IAS term for the code which 
actual services a peripheral. Device handlers are like 
device drivers, except that perform a part of their pro¬ 
cessing as a task and other service is kernel mode. 


Die stands for Directive Identification Code. Each RSX 
system directive has control block (DPB>. The first 
word is the DIC, which consists of a low-byte directive 
identifier and high-byte DPB size. 

Digital Command Language 
See DCL. 

Directive 

Requests for system functions from user tasks are called 
directives. A user task forms a control structure that 
identifies the directive and holds parameters and issues 
an CMT instruction to pass control to the executive. 
RSX supplies a complete set of Macro-11 macros for as¬ 
sembly language programs to construct and issue direc¬ 
tives. A similar subroutine library is provided for 
Fortran code. 

The RSX directives allow tasks to obtain task and system 
information, measure time Intervals, perform I/O, start 
and control other tasks, communicate with other tasks, 
manipulate the virtual and logical address space, wait 
for events in the system, and exit from the system. See 
DPB, DIC. 

Directive Identification Code 
See DIC. 

Directive Parameter Block 
See DPB. 
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Directive Status Word 
See DSW. 

D i rectory 

A directory is a file that briefly catalogs a set of 
files stored on disk or tape. The directory includes 
the filename, type, and version and also has a pointer 
to the actual file. 

RSX breaks directories into two classes. The MFD (Mas¬ 
ter File Directory) is the directory that catalogs the 
directory files. UFD's (User File Directories) are the 
actual catalogs for files. 

Note that a file's directory entry is Independent of the 
file itself and one can exist without the other. For 
example, temporary files are created without directory 
entries and therefore must be deleted when a program is 
finished with them. 

Disk-Reside nt 

Disk-resident is that which resides on a disk until 
needed . 

Disk Swap ping 

Disk Swapping is a RSX mechanism for allowing tasks at 
the same priority to compete equally for memory. Disk 
swapping and its associated priority have nothing to do 
with the actual priority a task competes for the CPU, 
although obviously a task must be in memory in order to 
execute. 

Disk swapping works on the basis of a swapping interval 
and priority. Each time a task is loaded into memory, 
the executive sets the priority it competes for memory 
to the task priority plus the swapping priority. At 
each swapping interval, all memory priorities are decre¬ 
mented. The minimum value is the task priority minus 
the swapping priority. After every interval, the execu¬ 
tives checks to see if some task waiting for memory is 
now greater in priority than tasks currently in memory. 
If so, a checkpoint is initiated. 

For an example, consider a partition large enough to 
hold either task A or B and swapping interval of 1 sec¬ 
ond and priority of 3. Both A and B have a normal pri¬ 
ority of 50. When A is loaded, its memory priority is 
set to 53 and after one second drops to 52. When after 
4 seconds the value drops to 49, the executive will 
checkpoint A out of the system and load in B. A will 
now have a priority of 50 and wait until task B's memory 
priority drops to 49. 
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DMA 


DMA stands for Direct Memory Access. DMA is the techni¬ 
que fast devices like disks use to transfer to and from 
memory. The devices is told the starting physical ad¬ 
dress and size of transfer and then does the operation 
without any further program control. The device will 
then signal an interrupt when the transfer is complete. 

DM0 

DM0 is the RSX system task for disabling access to a 
disk or magtape volume. This process is called dis¬ 
mount! ng . 

DMP 

DMP is a RSX utility for outputting RSX files in a vari¬ 
ety of formats, including octal, ASCII, RAD50, and hexa¬ 
decimal. 

DPB 

DPB stands for Directive Parameter Block. A DPB is the 
user task control structure that holds the information 
for the executive to use when processing a directive. 

Driver 

See Device Driver. 

DSC 

DSC is a RSX utility for making a volume copy of a disk 
to either another disk or magtape. DSC also performs 
the function of compressing the unallocated space on the 
disk into one contiguous fragment. 

D-Sp ac e 

D-Space refers to one of the two addressing spaces of 
the PDP-11 memory management unit. If enabled, all data 
references use separate D-space PAR/PDR registers to re¬ 
solve the reference. The use of D-space allows the vir¬ 
tual address space of a task to expand to 64 KW's, 32 
for instructions and 32 for data. Only RSX-llM-Plus 
supports D-space. 

DSR 

DSR stands for Dynamic Storage Region. See Pool. 

DSM 

DSW stands for Directive Status Word. This is a special 
word in a task which is used to return success/failure 
information for all directives. RSX convention is a po¬ 
sitive number is directive success and a negative value 
is some from of directive failure. 
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Dynamic Storage Region 
See Pool. 

EAE 

EAE stands for Extended Arithmetic Element and is an ob¬ 
solete option used on early PDP-11's for multiple and 
divide support. 

EDI 

EDI is the traditional RSX editor. It is a 
line-oriented editor with a a very simple command set. 
It is the easiest and least complex of the editors ava¬ 
ilable for RSX to learn. 

EDT 

EDT is the Digital standard editor and is available on 
most Digital operating systems. EDT main power comes 
from its video editting mode available for VT-series 
terminals. 

EIS 

EIS stands for Extended Instruction Set. EIS instruc¬ 
tions are now standard features on PDP-11 processes and 
include the MUL, DIV, ASH, ASHC, XOR, and SOB instruc¬ 
tions. EIS instructions are not available for early 
PDP-11 model <PDP-11/10 and 11/20) and is an option on 
some (PDP-11/35 11/40). 

ELI 

ELI is a RSX system utility for controlling the error 
logging system. See Error Logging. 

EMT 

EMT is a set of PDP-11 Instructions that cause a trap to 
the executive through vector 30. EMT instructions are 
used in RSX to pass control to the executive for direc¬ 
tive processing. Sometimes EMT is used as a synonym for 
RSX directives. 

EOF 

EOF stands for End-of-File and refers the the logical 

end point of a file. EOF's are a function of FCS/RMS 

and not Files-11. Both FCS/RMS maintain the last point 
data was written and do not allow read access beyond 
this point. 

ERL 

ERL is the RSX system task that actual performs error 

logging. The executive passes error packets to ERL 

which then records them to a disk file. See Error Log¬ 
ging. 
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Error Logging 

Error logging is a RSX system feature to record various 
information about hardware errors and output annotated 
listings on the errors. The RSX error logging system 
handles errors detected by devices when performing I/O 
operations, Interrupts that are unexpected, and memory 
and cache parity problems. 

Event Flag 

An event flag is a single bit indicator that is used to 
synchronize programs with events. A variety of RSX di¬ 
rectives allow tasks to read, clear, and set event 
flags, as we I I as wait for an event flag to set. Also, 
almost all events in a RSX system, such as I/O comple¬ 
tion, can be associated with an event flag. Mhen the 
event occurs, the executive will set the event flag. 

Event flags are addressed by number and range from 1 to 
96. This range is further broken down into 3 32-bit 
classes: local, global, and group global. 

EXCOMl/2 

EXCOMl/2 are the names of the executive extension re¬ 
gions. These are partitions that holds executive code. 
The executive maps the regions directly when it needs 
them. 

Executive 

Executive is a general word for the code and processing 
which comprising the basic part of the RSX operating 
system. 

Extend 

Extend means to add additional space to the end of an 
object. In RSX this usually means to add more virtual 
address space to a task or more disk blocks to a file. 

Extended Instruction Set 
See EIS. 

External Task Header 

External Task Header's is a RSX-llM-Plus feature that 
puts the task header directly in front of the task image 
in memory and not in system pool like in RSX-llM. 

FllACP 

FllACP Is the special RSX system task that implements 
the Files-11 disk structure. FllACP Is a ACP and pro¬ 
cess the Files-ll QIO's. 


F4P 

F4P is shorthand for the Fortran-IV-PIus compiler. This 
is a separate product and supports the ANSI 66 Fortran 
standard with extensions. F4P assumes the availability 
of the EIS and FPP instructions. 

F77 

F77 is shorthand for the Fortran-77 compiler. This is a 
separate product with origins from F4P. F77 supports a 
subset of the ANSI 77 Fortran standard. 

FCB 

FCB stands for File Control Block. FCB's are the execu¬ 
tive data structure which hold the necessary information 
about open files. FllACP creates a FCB for each time a 
file is first opened on the system. FCB's can come from 
either FllACP's internal buffer space or system pool 
when that is exhausted. 

FCP 

FCP stands for File Control Primitives. These are the 
various QIO's which make up the functions available from 
a user program for accessing files on a disk or magtape 
volume. 

FCS 

FCS is shorthand for File Control Services. FCS is a 
set of routines linked directly to a task that provide 
device independent I/O and primitive record management. 
FCS subroutine calls break down the user I/O request 
into specific QIO's for the actual device. 

FOB 

FOB is an acronym for File Descriptor Block. This is 
the main control structure used by FCS and contains in¬ 
formation about the type of I/O being performed from a 
user program. 

File Contro I Block 
See FCB. 

File Control Primitives 
See FCP. 

File Control Services 
See FCS. 

File Descriptor Block 
See FDB. 
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Fite Header 

A file header is one disk block the holds all informa¬ 
tion about a file. It includes attributes used by 
FCS/RMS to determine the internal record structure and 
the mapping pointers for virtual disk blocks to the ac¬ 
tual physical disk blocks. 

File Name Block 
See FNB. 

File Specification 

A file specification is the unique identification of a 
file. The convention for file specification is: 

ddnn:Cg,m3fi lename.typ;version 

The device name <ddnn:> is a two-letter mnemonic, an 
octal number from 0 to 77, and a terminating colon. The 
UIC specification (Cg,o3) is a pair of octal numbers 

that range from 0 to 377. UIC’s are enclosed in brack¬ 
ets and the two numbers are separated by a comma. The 
filename is one to nine character alphanumeric string 
and the filetype is a one to three character string. 

They are separated by a period. The version number 

(;version) is an octal number which is always preceded 
by a 8 emi CO I an. 

File-ID 

File-ID is a pair of numbers which uniquely identify 

each file on a volume. The first number is the position 
of the file header In the index file. The second number 
is cal led the sequence number and is the number of times 
the header has been used to for a file header. Whenever 
a file is created, the current sequence number is incre¬ 
mented by one. 

The mapping from a file directory entry to the file 
header is by the File-ID. If a File-ID is already known 
for a file, directory processing can be skipped. 

Files-11 

Files-11 is a term for the on-disk structure used by RSX 
for files. It also applies to the various user func¬ 
tions available to access files. 

FIS 

FIS is a hardware option for the PDP-11/35 and 11/40 
processors that provide four simple instructions for 
floating arithmetic. 
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Floating Instruction Set. 
See FIS. 

Floating Point Processor 
See FPP. 


FLX is a RSX system utility for transfering files 
between RSX systems and other PDP-11 operating systems. 
FLX understands RT-11 disk formats and DOS magtape for¬ 
mats. 

FMT 

FMT is a RSX system utility for formatting disk packs. 

FNB 

FNB is shorthand for Filename Block. This is the struc¬ 
ture used by FCS to name files. The parsing logic of 
FCS takes dataset descriptors and template filename 
blocks to construct the actual FNB. 

Fork 

Fork is a term applied to the RSX executive's mechanism 
for serializing access to the executive and its data¬ 
bases. Whenever an interrupt service routine needs to 
drop processing down from interrupt level to executive 
level, it performs a fork. An example of this would be 
when a device error occurs and needs to be logged or the 
interrupt service routine detects I/O completion. 

The fork process queues an entry to the fork I ist. When 
the executive finishes its current process, it checks 
the fork queue before returning to a user task. 

FPP 

FPP stands for Floating Point Processor and is a 
hardware feature for most PDP-11 CPU’s to implement flo¬ 
ating point instructions. FPP supports integer to flo¬ 
ating conversion and single and double precision float¬ 
ing notation. 

FTB 

FTB is a RSX utility for fast task building. It has 
only limited powers but is three to four times faster 
for simple task builds. 

Global Event Flags 

Global event flags are event flag numbers 33 to 64. 
These event flags are seen by all tasks in the system 
and therefore can be used for intertask communication. 
For example, convention at a site could say the applica¬ 
tion system is to shutdown gracefully if global event 
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flag 35 is set. All application tasks would then peri¬ 
odically check the state of this flag and being shutdown 
operations if they find it set. See Group Global Event 
Flags and Event Flags. 

Global Symbol 

A global symbol is a symbol defined in one object module 
that can be referenced in another object module. Global 
symbols are identified and defined by the Task Builder. 
An example of a global symbols would be the subroutine 
name of a Fortran routine. 

Group Global Event Flags 

Group global event flags are event flag numbers 65 to 
96. There can actually be many sets of these event 
flags. The sets are addressed by a tasks group number. 
All tasks at the same group see the same set of group 
global event flags. There are executive directives to 
create and destroy group global event flag sets and to 
Iock the Ir existence. 

Group Number 

Group number is the first part of the account (UIC> 
pair. Group numbers are expressed in octal and range 
from 1 to 377. See Account and UIC. 

Handler 

See Device Han dIe r. 

Hang 

When a terminal, task, or system is going nowhere and 
doing nothing useful, it is said to be hanging. Hanging 
results from many different causes. Some of the more 
frequent are exhaustion of system resources, deadlock, 
and program loops. 

Header 

See Task He ade r. 

$HEADR 

$HEADR is a RSX system variable that has the address of 
the current task header. This location is updated whe¬ 
never a context switch is made to another task. 


HEL is a RSX system utility to initiate a terminal ses¬ 
sion. HEL identifies you to the system, establishes any 
privileges you may have, and set the CLI to initially 
use from the terminal. HEL also processes all requests 
for HELP. 
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HOM 

HOM is a RSX system utility to change the volume attri¬ 
butes of a already initialized disk. 

Home Block 

The home block is the root information for a Files-11 
disk volume. The home block is usually the second phy¬ 
sical block on a disk. If this block is bad, the home 
block is placed at the first good block found at multi¬ 
ples of 256. The home block has all necessary informa¬ 
tion for FllACP to find the rest of the Files-11 struc¬ 
tures. 

ICP 

ICP is the RSX system task for processing indirect com¬ 
mand files. 

Index File 

Index File is the area on a disk structure which com¬ 
prises the control Information for the Files-11 volume. 
The index file shows up as an actual file on the disk 
(CO,ODINDEXF.SYS>. It contains the boot and home blocks 
as Its first two blocks, followed by other special in¬ 
formation. The majority of the index file is made up of 
individual file headers. 

Indirect Command Fi le 

An indirect command file is a file processed by the ICP 
task. The command file consists of special directives 
that control the processing done by ICP and commands for 
ICP to pass to the CLI. The directives available in in¬ 
direct command files are sufficient to consider them as 
a programming language: flow control, input and output, 
and variable and character operations. 

IND 

IND is the RSX system task for processing indirect com¬ 
mand files available on RSX-llM V3.2 and earlier sys¬ 
tems. IND was enhanced and renamed to ICP in RSX-llM 
V4,0. 


INI is the RSX system utility used to create the initial 
Files-11 on-disk structure. INI creates a blank index 
file and establishes the volume characteristics. Doing 
an INI on a volume completely loses any previous struc¬ 
ture on the disk. 

INS 

INS is the RSX system utility for installing a task. 
See Install. 
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I nsta I I 

Install is a term in RSX that refers to making a program 
known to the system and available for execution. All 
programs are contiguous files known as task images. 
Until a task image is installed, it cannot be executed. 
Installing a task is a process of reading information 
from a task header and constructing a TCB. See 1CB. 

Inte rrupt 

The mechanism used by PDP-ll's to signal changes in dev¬ 
ice status is known as an interrupt. There are also In¬ 
structions (LMT, TRAP, BPT, lOT) and illegal conditions 
(odd address, illegal instruction) that are also inter¬ 
rupts. 

When an interrupt occurs, the current program counter 
and processor status are pushed onto the stack and a in¬ 
terrupt vector is used to supply a new program counter 
and processor status. This causes control to pass to 
code to service whatever specific condition is being 
signa I ed . 

Inte rrupt Vector 

An interrupt vector is an transfer vector, processor 
status pair in the first 1000 words of physical memory. 
Each interrupt in a PDP-11 are tied to a specific inter¬ 
rupt vector so control can be passed to the correct ser¬ 
vice code . 

Interrupt Transfer Block 
See ITB. 

I/O Meehanism 

I/O mechanism is a term applied to the various compo¬ 
nents used In a RSX system for device input and output. 
The I/O mechanism can be broken down to four distinct 
levels: FCS/RMS, QIO, ACP's, and device drivers. 

FCS/RMS comprise the top level of the I/O mechanism and 
provide for device independence and record management. 
These are routines linked directly to user tasks and 
perform much of the bookwork required to interface with 
the lower levels. 

The QIO is the directive used to signal I/O from a user 
task to the RSX executive. All I/O, including that ac¬ 
tual ly performed by FCS/RMS is done using a QIO. The 
executive performs common processing on the request and 
then forwards it to the specific function handler. This 
can either be an ACP or device driver. 

ACP’s are tasks which implement high-level protocols for 


classes of devices, such as the on-disk structure or 
ANSI labeled tapes. Many of the QIO's issued from user 
tasks are not specific to the device but instead routed 
by the executive to ACP's. These tasks process the re¬ 
quest in a variety of forms, which include issuing QIO's 
of their own for specific device functions. 

Device drivers form the bottom of the I/O mechanism and 
perform device specific I/O operations. 

I/O Packet 

An I/O packet is the internal executive representation 
of a QIO directive. The I/O packet is the control in¬ 
formation passed to either an ACP or device driver for 
further processing. 

I/O Page 

All PDP-ll's consider the last 4 KW's of their physical 
address space as a special area known as the I/O page. 
Instead of memory, this space has device registers for 
all peripherals on the system. 

I/O Rundown 

I/O rundown is a term for the state a task enters when 
it tries to exit but alI outstanding I/O cannot be com¬ 
pleted. RSX keeps track of outstanding I/O requests and 
open files for a task and tries to clean these up when a 
task exits. If an error in the system causes the clean¬ 
up to fail, the task will get stuck in I/O rundown state 
and remain in limbo until some other action is taken 
(like rebooting the system). 

lOX 

lOX is a RSX system utility for exersing the devices on 
the system. lOX will place a heavy I/O load on as many 
parts of the system as the user selects. 

1 -Space 

I-Space refers to one of the two addressing spaces of 
the PDP-11 memory management unit. If enabled, all in¬ 
struction references use separate I-space PAR/PDR regis¬ 
ters to resolve the reference. I-space is also the de¬ 
fault mode for all references for memory management 
units that do not have D-space implemented and for those 
units that have D-space disabled. 

ITB 

ITB is shorthand for Interrupt Transfer Block. This is 
an executive data structure used to pass control for an 
interrupt to a loadable device driver. The interrupt 
vector for the device points to the ITB and the ITB then 


41 


42 



maps the loadable device driver and passes control to 
its interrupt service routine. 

KMS Fusion Kit 

The KMS Fusion Kit is a major submission on the RSX SIG 
tapes that covers two primary areas: RSX-llM accounting 
and CCL. The kit has been submitted to many tapes and 
is always found in C344,*3. The latest version for 
RSX-llM V4.0 is on the Atlanta Spring 1982 tape. 

Kernel 

Kernel Is a term used in RSX to refer to any type of ex¬ 
ecutive processing and in general a synonym for execu¬ 

tive. 

Kernel Mode 

Kernel mode is a processor state on the PDP-11. It is 
the most privilege of the three processor states (ker¬ 
nel, supervisor, user) and has no restrictions on in¬ 
structions that can be executed. All executive process¬ 
ing is done in RSX in kernel mode. Switches to kernel 
mode from higher levels are accomplished through the in¬ 
terrupt vectors, which set the vector address and pro¬ 
cessor state. When in kernel mode, the memory manage¬ 

ment unit uses the kernel address registers for virtual 
to physical memory mapping. 

Kernel Stack 

The kernel stack is the stack used by the executive when 
processing in kernel mode. It sits immediately above 
the vector space. A PDP-11 that supports memory manage¬ 
ment has a separate stack pointer register for each pro¬ 
cessor mode. When a switch is made from one mode to 
another, the stack pointer register is also switched. 

Layered Product 

A RSX layered product is a separate product available 
from Digital that requires RSX. Examples of layered 
products include all languages (F77, Basic-P I us-2>, DEC- 
net, and SORT-11 . 

LB: 

LB: is a pseudo device that is redirected when a system 

is bootstrap to the disk booted from. LB: is the de¬ 

fault disk for almost all RSX system files. 

LBR 

L6R is a RSX utility for creating and manipulating li¬ 
brary files. See Library. 
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LCB 


LCB is shorthand for Logical Control Block. An LCB is 
an executive data structure and holds the information 
necessary to translate a logical device assignment to 
the real device. The MCR ASN command is used to create, 
destroy, and list LCB's. 

LDR 

LDR is a RSX-llM system task that is directly interfaced 
in the executive. LDR is used to load task images and 
for the checkpointing of tasks to and from disk. 

Library 

A library is a file which contains related types of 
files. The primary use of library files is to hold col¬ 
lections of macro definitions and object modules. The 
Macro assembler and task builder have facilities to re¬ 
trieve macros and objects from these libraries. RSX 
also provides a type of library termed universal. Such 
libraries can hold any type of file and are a convenient 
method for packaging many small files. 

LOA 

LOA is a RSX system task that is used to read a loadable 
device driver Into memory and initialize the system so 
the device can then be used for I/O operations. See Lo¬ 
adable Driver. 

LoadableDriver 

A loadable driver is a device driver that is not ini¬ 
tially built into the kernel executive. Instead, the 
driver is loaded into a partition using LOA or VMR. The 
advantage of loadable drivers is that the driver does 
not take up space in the kernel executive. This frees 
space for pool. See Device Driver. 

Loadable Database 

Loadable database refers to a loadable device driver 
that follows some specific conventions so the actual 
device database is a part of the driver image on disk. 
When the loadable driver is loaded into the system using 
LOA or VMR, the template database in the image is used 
to created the normal device database. Space for this 
database comes from system pool. The advantage of load¬ 
able databases is that they allow new devices to be 
added to the system without an entire new system genera¬ 
tion. Note, loadable databases are not destroyed when 
the driver is unloaded. 

Loader 

See LDR 
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Local Event Flags 

Local event flags are event flag numbers 1 to 32. 
task has its own copy of local event flags. 

Local SymboI 

A local symbol is a definition that cannot be referenced 
outside of the object module that has its definition. 

Local User Group 
See LUG. 

Locked Block 

A locked block is a block is a disk file that can only 
be read and written by the task that locked it. This 
mechanism is used in RSX-llM to allow multiple tasks to 
open the same file and still safely allow update access 
to the file. 

Logical 

Logical is used in RSX as a synonym for physical. See 
Logical Block, Logical Address Space, and Virtual. 

Logical Address Space 

The total amount of physical memory to which a task has 
access rights. The memory management unit performs the 
translation between virtual addresses and logical ad¬ 
dresses. The PLAS directives allow a task to change 
their virtual address to map different logical ad¬ 
dresses. See Virtual Address Space. 

Logical Block 

A logical block is the actual block on the disk. FllACP 
and the executive are responsible for mapping a file 
virtual block to the actual logical blocks. The Window 
Block has this mapping information. See Virtual Block. 

Logical Control Block 
See LCB. 

Logical Device 

A logical device is a device name that maps into a phy¬ 
sical device. Logical devices are created, listed, and 
destroyed by the ASN command and provide a useful method 
for assigning devices independently of the actual dev¬ 
ices used at any one point in time. 

Logical Unit Number 
See LUN. 

Lost File 

A lost file is a file that has no directory entry and 
therefore can only be accessed by file-ID. One function 


45 


of the VFY utility is to find lost files and create a 
file directory entry for them. 

LUG 

LUG is an acronym for Local User Group. LUG’s are small 
groups of DECUS formed In a specific area by users with 
specific interest. 

LUN 

LUN stands for Logical Unit Number. A LUN is a number 
associated with a physical device during a task's I/O 
operations. Each task establishes its own correspon¬ 
dence between LUN's and devices. 

MAC 

MAC is the name of the RSX assembler. The assembler 
language is called Macro-11 and has an extensive set of 
directives in addition to support the actual instruction 
n 0 ta tion. 

Macro 

A macro is a single assembIy-Ianguage statement that ex¬ 
pands into a predefined set of other assembIy-I anguage 
statements. Macros may have arguments which are substi¬ 
tuted by the MACRO-11 assembler when expanding the 
macro. 

Macro Library 

A macro library is a collection of macros packaged into 
a file by LBR. The Macro-11 assembler has a directive 
<.MCALL) which will cause searches of macro libraries. 

MAG 

MAG is a RSX system utility for manipulating magnetic 
tapes . 

Manual Load 

This is a method of loading overlay segments in which 
the user makes explicit calls in his task to load over¬ 
lays and handle unsuccessful load requests. 

Mapped 

Mapped refers to a RSX system that has support for the 
PDP-11 memory management unit. 

Mapping directives. 

A synonym for the PLAS feature of RSX. Refers to the 
set of directives which allow a task to change its vir¬ 
tual addressing. 
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Mark Time 

The Mark Time directive cases an event to occur at some 
interval in the future. The task can be notified when 
the time elapses by either a event flag or AST. 

MASSBUS 

MASSBU8 is a name for the disk and magtape controllers 
used on a PDP-11/70. These controllers provide direct 
access to 11/70 memory. 

Master File Directory 
See MFD. 

MCR 

MCR stands for Monitor Console Routine, the prime inter— 
face for a user with a RSX system. MCR receives all 
commands and either operates on them diretly or dis¬ 
patches them according to its special parsing rules. 
MCR commands tend to use initials or acronyms in a 
strict syntax, rather than the English like syntax of 
DCL. 

Memory Management 

Memory management refers to the hardware option on most 
PDP-ll's that allows the system to use more than the 
32KW ■ s directly addressable in the PDP-11 16-bit ad¬ 
dress. The memory management system takes each 16-bit 
address and maps it to the correct physical address. 

Memo ry-Residen t 

In general, that which resides in memory all the time. 
The entity, as in the case of memory-resident overlays, 
may initially reside on disk. Once loaded it stays in 
memo ry. 

Memory-Resident Overlay 

An overlay that shares virtual address space with other 
overlay segments, but which resides in its own physical 
memory. The segment is loaded from disk only the first 
time it is referenced. Thereafter mapping directives 
are issued in place of disk load requests. 

MFD 

Each Files-11 volume has a Master File Directory (MFD). 
This is a special file that contains pointers to all 
User File Directories on the system. The MFD itself is 
directory C0,0]. 

Monitor Console Routine 
See MCR. 


MOU 

MOU is the RSX system utility for reading the Fjles-11 
information found on a disk and setting up the necessary 
RSX data structures so the files on the volume can be 
accessed. 

MTAACP 

AN ACP task that implement support for ANSI labeled 
tapes. MTAACP uses Files-11 QIO's to access such tapes. 

Multi-Tasker 

The Multi-Tasker is the newsletter of the RSX-ll/IAS 
SIG. It has been published monthly since 1976, except 
for the current year where budget cuts forced temporary 
bimonthly schedules. 

Multi-Use r Task 

An RSX-llM-Plus or IAS task that has the read-only re¬ 
gion of the code shared among several copies of the same 
task. Each task has its own copy of the read/writedata 
areas. 

NL : 

NL: is the null device, a special device driver that 

provides a sink for all output and EOF signals for all 
input. The devices main use is to discard listing out¬ 
put. This is done by assigning a logical device to NL: 
whenever listings are not desired. 

Null Device 
See NL: 

Object Library 

An object library is a collection of object modules 
packaged into a file by LBR. The task builder under¬ 
stands the format of object libraries and get extract 
modules from them to resolve global references. 

Object Module 

An object module is a file that is the output of the 
Macro-11 assembler or the various RSX language com¬ 
pilers. Object modules have binary representation of 
the code desired by the programmer and are used as input 
to the task builder for creating the executable' image. 

Object Time System 
See 0 T S. 

OCB 

OCB stands for Offspring Control Block. This is the ex-- 
ecutive data structure used by RSX to tie offspring 
task's to their parent tasks. OCB's are created in sys- 
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tern pool and linked to the offspring task. 

ODL 

ODL stands for Overlay Descriptor Language and is the 
type of file supplied to the task builder to define how 
it should setup overlays. 

ODT 

ODT is the On-line Debugging Tool. ODT is an object mo¬ 
dule that when linked with a task allows the user to ex¬ 
amine and deposit locations in the task, set breakpo¬ 
ints, and single step the task's execution. 

Offspring Control Block 
See OCB. 

OTS 

OTS is shorthand for Object Time System. Each language 
aval lable on RSX has a set of object modules that are 
used by the code generated by the language compiler. 
This code, called OTS, is linked to user programs auto¬ 
matically by the task builder. Because all programs 
written in the same language will use the same OTS rou¬ 
tines, a common practice is to link the OTS routines in 
a resident library and share the code among tasks. 

Overlapped Seek 

Overlapped seek refers to starting the search for a 
specified disk block on one disk drive while performing 
a disk transfer on another drive. Most of the disks 
supplied by Digital have this ability but only 
RSX-llM-Plus implements this feature. 

Overlay Description Language 
See ODL. 

Overlay Runtime System 

A set of system library routines that the task build au¬ 
tomatically links into an overlaid program to perform 
all overlay load and mapping requests. 

Over lay Segmen t 

A segment that shares virtual address space with other 
segments and is loaded when needed. 

Owner Number 

Owner number is the second part of the account <UIC> 
pair. Owner numbers are expressed in octal and range 
from 1 to 377. See Account and DIG. 
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Page Address Register 
See PAR. 

Page Descriptor Register 
See PDR. 

PAR 

PAR stands for Page Address Register. It is also re- 
fered to as APR or Address Page Register. PAR’S are a 
part of the PDP-11 memory management mechanism and there 
are a total of eight PAR registers for each of the vari¬ 
ous addressing spaces (kernel, user, etc.) A PAR regis¬ 
ter contains the starting physical address of a 4 KM 
virtual address. 

Partition 

A partition is a contiguous area in memory in which 
tasks are loaded and executed and data can be stored. 
RSX has three types of partitions: tasks, common, and 

system. The first two are static and can be used for 
tasks and data respectively. System partitions are al¬ 
located dynamically into subpartitions. 

Partition Control Block 
See PCB. 

PAT 

PAT is a RSX utiIity for making patches to object mo¬ 
dules. PAT is used by Digital to correct distribution 
software which is not in source form. 

PC 

PC stands for Program Counter and is register 7. This 
is a special register and always contains the next ad¬ 
dress to fetch for instructions. 

PCB 

PCB stands for Partition Control Block. PCB's are the 
executive data structure used to define each region of 
physical memory that is in use. PCB's are linked to¬ 
gether in pool by increasing physical address. The 
space between two successive PCB's is is the unused 
space that can be allocated. 

PDP 

PDP stands for Programmable Data Processor. When Digi¬ 
tal first made computers, the industry would not accept 
a computer for less than $100,000. Digital decided to 
name it's machines Programmable Data Processors to get 
around the prejudice of the time. 
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PDR 


PDR stands for Page Descriptor Register. POR‘s are used 
by tbe memory management unit to describe the length of 
a page and the type of memory access allowed. 

PhysicaI Address 

The actual byte locations in real memory. 

Physical Device 

A physical device is a real device. Logical and pseudo 
devices will finally map into a physical device. 

PIC 

An acronym for PosItion-Independent Code. PIC allows 
the code to be placed anywhere in a task's virtual ad¬ 
dress space without relocating the actual addresses. 

PIP 

PIP is the RSX utility for handling files. PIP major 
functions are copying files, listing directories, and 
deleting files. 

PLAS 

PLAS stands for Program Logical Address Space and is a 
set of directives that allow a task to create and des¬ 
troy regions in memory and change its virtual mapping in 
these regions. PLAS allows a task, under program con¬ 
trol, to overcome the 32KW addressing restriction of the 
PDP-11 by providing a user interface to the memory man- 
agemen t unit. 

PHD 

PHD is a RSX system task for output a formatted dump of 
a task or particular part of a task (cal I snapshot). 
PHD is normally used to dump a task when it aborts so 
you can find the reasons for the error. 

PHT 

PHT is the special RSX system task used for pool moni¬ 
toring. See Pool Monitoring. 

Poo I 

Pool refers to the space in the executive used to hold 
RSX executive data structures. The structure of RSX-llM 
limits the size of thekernel executive to the first 
20KM of physical memory. Pool is whatever space is left 
in this space after subtracting out the kernel code. 

RSX-llM-Plus extends the available pool because the exe¬ 
cutive uses I/D-space and a second area for some struc¬ 
tures. 


Almost every RSX function requires some allocation of 
pool. If the space cannot be found, and error is re¬ 
turned and the operation fails. Low pool is the most 
common type of failure for a RSX system. 

Pool Monitoring 

Pool monitoring is a RSX executive feature that allows 
some action to be taken when system pool is critically 
low. The RSX executive keeps track of pool allocations 
and will notify the pool monitoring task <PMT> when var¬ 
ious threshholds are crossed. If pool becomes exhaust¬ 
ed, the pool monitor task will take complete control of 
the system and allow the system manager to abort select¬ 
ed task to recover their allocations. 

Pool Fragmentation 

Pool fragmentation refers to the state when enough pool 
is free for most requirements but the space is so scat¬ 
tered into little chuncks that allocations cannot be 
made. Pool allocation is by a first-fit algorithm and 
over time the free pool will become fragmented. 

Pop 

Pop means removing an item from the stack. 

Position Independent Code 
See PIC. 

Post-Mortem Dump 
See PMD, 

Privilege Task 

A task that has no restrictions on the executive ser¬ 
vices it can use. A class of privilege tasks are mapped 
to the executive and the I/O page and therefore can di¬ 
rectly address pool structures and devices. 

Processor Status Word 
See PSW. 

Program Counter 
See PC. 

Program Logical Address Space 
See PLAS. 

Protect!on Code 

Each file has a protection code that specifies what ac¬ 
cess different categories of users have to the file. 
The catagories are selected by comparing the UIC associ¬ 
ated with the file and the UIC of the program making the 
access. RSX has four categories: system, owner, group. 
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and world. For each category, four levels of file pro¬ 
tection can be named: read, write, extend, and delete 
access. 

PSECT 

Memory allocation for various code segments when a pro¬ 
gram is linked in established by attributes assigned to 
program sections. PSECT is the Macro-11 directive for 
setting these attributes. 

Pseudo Device 

A pseudo device is an entity treated as an I/O device by 
the system by is not a real device. Instead pseudo dev¬ 
ices are always mapped to an actual physical device. 
Pseudo devices allows programs to refer to devices with¬ 
out actual knowing the real name. For example, LB: 
always points to the system disk no manner which actual 
disk is booted. 

PSW 

PSM is shorthand for Processor Status Mord. The PSM is 
the last word in the I/O page (and therefore in physical 
memory space) and has the current execution status. The 
PSW is broken Into three bits fields. The first has the 
current and previous processor state (kernel, supervi¬ 
sor, and user) and determines what memory management re¬ 
gisters will be used. The next is the processor priori¬ 
ty and ranges from 0 to 7. This controls what devices 
will be allows to interrupt the processor. The final 
bits are condition codes and have information on the re¬ 
sult of the last Instruction. 

Push 

Push means adding an item to a stack. 

QIO 

QIO is the directive RSX uses for all I/O requests. 

QHG 

QMG is the RSX task that manages the queue of Jobs di¬ 
rected to the batch processor, line printer, or other 
spoo led devices. 

Queue 

Q queue is a waiting line of items waiting to be pro¬ 
cessed. RSX has a queue manager for batch and spooled 
Jobs. Also, almost all executive lists are maintained 
as queues ordered by task priority. 

Queue Manager 
See QGR. 
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RAD50 

RAD50 is a coding convention for the uppercase alphabet¬ 
ic characters, decimal digits, blank, period, and dollar 
sign. Three of these characters can be packed into one 
word. The executive uses RAD50 packing for almost all 
of its character storage as a space saving tool. 

Record Management Service 
See RMS. 

Reentrant Code 

Reentrant code means code that can be executed by more 
than one process at a time. Reentrant code must keep 
all local variables on a stack. 

Region 

A region is a contiguous block of physical memory in 
which a task, driver, resident common, or library re¬ 
sides. The PLAS directives allows tasks to dynamically 
create regions. 

Remo ve 

Remove means to eliminate the TCB for a task so it can 
no longer be executed. 

Resident Commo n 

A resident common is a partition that holds data. 
Resident common's can be mapped by many tasks at the 
same time. This allows data to be shared and exchanged 
between tasks. 

Resident Library 

A resident library is a partition that holds instruc¬ 
tions. Resident libraries can be mapped by many tasks 
at the same time. This allows reentrant code to be 
shared among many programs, reducing the physical memory 
needed to run the programs. 

RMD 

RMD (also known as RMDEMO) is the RSX system utility for 
dynamically displaying the system status on a CRT 
screen. RMD will update its display once a second so 
you can visually see tasks enter and leave memory. 

RMS 

RMS stands for Record Management Services and is the 
more sophisticated of the two sets (FCS/RMS) of I/O rou¬ 
tines available on RSX systems. RMS has routines for 
normal sequential I/O and more complex record management 
of relative and index (keyed) files. RMS is common to 
many other Digital operating systems so programs written 
using RMS I/O are usually more portable that those writ- 
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ten with FC3. 


RNO 

See Runoff. 

Roun d-Robin 

Round-robin is a RSX system feature that gives tasks at 
equal priority in memory equal access to the CPU. 
Without round-robin scheduling, the executive would give 
the first task at a priority the CPU and not interrupt 
it for other tasks at the same priority. Round-robin 
works by rotating tasks at the same priority in the ATL 
at some fixed interval and causing a significant event. 
Note, round-robin scheduling has no effect on memory al¬ 
location. See Disk Swapping. 

RPT 

RPT is the RSX system utility for producing error log 
reports. RPT reads the binary information accumulated 
by the error logging system and outputs annotated infor¬ 
mation on each error. 

Runoff 

Runoff is a DECUS utility for document preparation. 
Runoff takes a mixture of free-formatted text and for¬ 
matting commands to output Justified, paginanted output. 
This document is prepared using Runoff. 


SAV is the RSX system task that takes a running, quiet 
RSX system and copies it the the system boot file. It 
then restarts the system from this file. 

Save 

Save in RSX refers to setting up a bootable system using 
the special system task SAV. 

SCB 

SCB is an acronym for Status Control Block and is the 
RSX executive structure that has the Information about 
each device controller in the system. 

Secondary Pool 

Secondary pool is a RSX-llM-Plus feature where certain 
executive structures are allocated from a second pool 
located in the system partition. This pool can be any 
size and helps increase the available space in system 
pool. 

Seek Optimization 

Seek optimization refers to a technique of examining the 
waiting I/O requests to a disk and selecting the next 
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request based on some algorithm that reduces disk I/O 
time. This functionality is only available on 
RSX-llM-Plus. 

Send-by-Reference 

Send-by-Reference is a set of directives that allow two 
tasks to exchange information on a region. These direc¬ 
tives area part of the PLAS functions. 

Send/Rece i ve 

Send/receive refers the mechanism of one task sending a 
fixed-length (13 word) message to another task. 

SHF 

SHF is a special RSX system task that moves tasks in a 
system partition to make more contiguous free space ava¬ 
ilable for loading tasks from disks. Whenever RSX tries 
to load a task in memory and faiis, it starts the 
shuffler which attempts to consolidate the partitions 
and free space at the top of the main partition. 

Shuf fIe r 

See SHF. 

SIG 

SIG stands for Special Interest Group. SIG’s a major 
part of the DECUS structure and subdivide DECUS into 
members with similar Interest. DECUS currently has 23 
active SIG's. Symposia sessions are oriented by SIG's 
and each SIG publishes a newsletter. 

SIG Tapes 

At each symposia since 1977, the RSX SIG has collected 
software from members and put on one master tape. This 
tape is then copied and distributed via LUG’s to all in¬ 
terested members. This collection is called the SIG 
tapes. Since the success of the RSX tapes, most other 
SIG's have initiated similar efforts. 

Significant Event 

A significant event is declared whenever there is a 
change in RSX system status, i.e. when an event occurs. 
When significant events are declared, RSX will review 
the status of ail blockes tasks to see if the event has 
unblocked them and made them eligible to run. Note, 
setting an event flag is often associated with a signi¬ 
ficant event but is not a significant event itself. 

Slaved Terminal 

A slaved terminal is a terminal that has no access to 
CLI's. Therefore no program can be initiated from a 
slaved terminal using MCR/DCL. 
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SLP 

SLP is the RSX utility used to make corrections to 
source files. SLP is a I ine-or i ented editor that ac¬ 
cepts text files with edit changes. 

Software Performance Report 
See SPR. 

SP 

SP stands for Stack Pointer and is a special PDP-11 re¬ 
gister (R6>. The various transfer control instructions 
use this register to save and restore the calling 
status. 

Special Interest Group 
See SIG. 

Spec if i ed AST 

A specified AST is an AST a task presets so it can re¬ 
ceive AST notification if the event occurs in the fu¬ 
ture. Examples of specified AST's include one for when 
a message is sent to a task or the system recovers from 
powerfai Iure . There is a separate directive for each 
type of specified AST. 

SPM-llM 

SPM-llM is a layered product for RSX-llM that collects 
RSX performance data and summarizes this data for ana¬ 
lysis. SPM puts hooks into the executive and records 
the occurence of almost every system event. 

Spooling 

Spooling refers the the process of sending I/O to a disk 
file and then queuing for transfer to sequential, 
non-shareab I e devices like line printers. 

SPR 

SPR stands for Software Performance Report and is the 
form used by Digital for users to report errors in 
software. 

SRD 

SRD is a popular DECUS utility that has a wide variety 
of directory operations. The major function is to sort 
directories and select files based on a wide variety of 
criteria. 

SST 

SST is an acronym for Synchronous System Trap. A system 
trap is a transfer of control that is caused by some 
event. RSX defines two types of system traps, synchro¬ 
nous (SST) and asynchronous (AST). 


An SST is a trap that occurs synchronous to program exe- 
cution. That is, the trap occurs as a direct result of 
program execution and will always occur in the same 
place if the same Instructions are executed. SST's usu¬ 
ally indicate a program error but can also be caused by 
specific instructions. Examples of SST's include odd 
address errors, TRAP instructions, and breakpoint traps 
< BPT instruction). 

A program can specify SST notification for different 
types of SST's. When the trap actually occurs, the exe¬ 
cutive interrupts the current execution and passes con¬ 
trol to the SST service routine. If no SST routine is 
enabled, the executive will abort the task. 

Stack 

A stack is a last-in, first-out temporary storage area. 
The instruction set on the PDP-11 has certain optimiza¬ 
tions that make stack operations easy. 

Stack Depth 

Stack Depth refers the mechanism the executive uses to 
determine what is the current execution state and what 
kind of transition Just took place. A system variable, 
$STKDP, is decremented each time there is an interrupt 
and incremented each time a return from Interrupt is 
made. The variable is set to one if running in a user 
task, zero if at executive state, and negative if pro¬ 
cessing device interrupts. 

Stac k Pointer 
See SP. 

STB 

STB is an acronym for symbol table and is a form of file 
output by the task builder. STB files hold the defini¬ 
tion for all global symbols in the task image. 

STD 

STD stands for System Task Directory and is a I inked 
list of all TCB's. Therefore, the STD is the list of 
all installed tasks in the system. 

$STKDP 

$STKDP is the global RSX system variable used as the 
stack depth counter. See Stack Depth. 

Stop State 

Stop state is a special wait state for tasks. A task in 
stop state does not compete for either the CPU or memo¬ 
ry. It can be swapped out by any task, including those 
of lower priority. Otherwise, a task in wait state does 
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not compete for the CPU but does retain its priority as 
far as memory allocation is concerned. 

Subpartition 

A subpartition is a subdivision of a system partition 
that is made by RSX to hold tasks and regions created by 
the PLAS directives. 

Supervisor Mode 

This is one of the processor modes of a PDP-11 and has a 
separate set of memory management registers and stack 
pointer. Supervisor mode support is only available with 
RSX-llM-Plus for supervisor libraries. This allows re¬ 
sident libraries to be used without subtracting from the 
task's user mode address space. 

Swap ping 

See Disk Swapping. 

SY: 

SY; is a pseudo device that stands for the users de¬ 
fault disk deviceT Each user has a unique SY: 
assignment. This allows easy distribution of users 
across various disks. 

Synchronous System Trap 
See SST. 

SY8CM 

SYSCM is the executive module that holds all RSX global 
variables. These include the listheads for all execu¬ 
tive data structures, current time information, and 
other executive control fields. 

Sysgen 

Sysgen refers to the process of creating a unique RSX 
system for your specific site needs. The process in¬ 
volves selecting the specific features and devices, as¬ 
sembling the executive source modules for those fea¬ 
tures, linking the executive and system tasks, and set¬ 
ting up the system as the bootable RSX system. 

SYSTB 

SYSTB is the executive module that holds the device data 
bases. This file is actually created on the fly by the 
sysgen process so it is unique to your system. 

System Control Block 
See SCB. 


System Controlled Partition 

A system controller partition is a type of partition 
that the RSX system controls allocation within. RSX 
will automatically create subpartitions in a system par¬ 
tition whenever a task load is requested. 

System Library 

The system library is an object library that 1KB de¬ 
faults to to resolve and undefined symbols after search¬ 
ing all other named libraries. The system library is 
named LB:C1,1TSYSLIB.OLB and typically holds the PCS 
routines, overlay system, and default language OTS mo¬ 
dules. 

System State 

System state means executing in the executive mode. 

System Task Directory 
See STD. 

Task 

The task is the fundamental, executable RSX program 
unit. The tradition computer program in a RSX system is 
a task. Tasks are created by the task builder from ob¬ 
ject modules and libraries. 

T ask Builder 
See TKB. 

Task Control Block 
See TCB. 

Task Header 

A Task Header is the low virtual address of a task that 
hold the task's initial and current context. 

Task Loader 

See LDR. 

TCB 

TCB stands for Task Control Block and is the RSX execu¬ 
tive structure that holds all the information necessary 
to run a task. TCB's are created when the task is in¬ 
stalled and destroyed when it is removed. The STD is 
the list of all TCB’s. The TCB’s in this chains that 
are for active tasks are also chained together ina sep¬ 
arate list called the ATL. 

TECO 

TECO is a character-oriented text editor available 
through DECUS and the RSX SI6 tapes. lECO is the one 
editor available on all Digital operating systems. Its 
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command sot is so powerful that ILCO could properly be 
considered as a programming language. 

Telephone Support Center 
See TSC. 

TI : 

TI: is a special RSX device that always references the 

terminal from where a task was initiated. A program can 
do I/O to the user terminal by assigning a LUN to device 
TI; and the executive will map to actual terminal. 
Normally LUN 5 defaults to TI;. 

TKB 

TKB is the RSX task builder. Essentially, TKB takes ob¬ 
ject modules as input and relocates the code to the cor¬ 
rect virtual address and resolves global references. 
TKB outputs a task image. This is a file which is ready 
to be installed and executed. 

TKN 

TKN is a special RSX system task that performs the error 
message processing when a task terminates abnormally. 

$TKTCB 

$TKTCB is a RSX system variable that always contains the 
address of the TCB for the current, active task. 

TPARS 

TPARS is a finite-state parsing mechanism that can be 
used to process any grammar. TPARS is implemented by a 
set of macros the user uses to describe the grammar and 
an object module that parses the supplied grammar ac¬ 
cording the states setup by the macros. 

Transparent Spooling 

Transparent spooling refers to capturing all output to a 
spooled device (line printer) and writing it to disk. 
When the I/O is complete, the mechanism queues the out¬ 
put for printing to the device. RSX-llM does not have 
transparent spooling. IAS and RSX-llM-Plus have this 
mechanism. 

TSC 

TSC stands for Telephone Support Service. TSC is a 24 
hour, seven day a week service for answering questions 
about RSX. 

UCB 

UCB is an acronym for Unit Control Block and is the exe¬ 
cutive data structure for each device unit. 


UFD 

UFD stands for User Fite Directory and is a file that 
contains the names of all files found in the user ac¬ 
count. UFD is also the RSX system task that creates the 
initial empty directory files. 

UIC 

UIC is the two-number user identification code that RSX 
uses to identify different people. UIC's are expressed 
in the form Cg,oD with "g" being the group number and 
"o” the owner number. People working together are typi¬ 
cally put in the same group because the file protection 
mechanism allows group members to have access to each 
others files. 

UMR 

UMR stands for Unibus Mapping Register and is the 
hardware feature used on 22-bit PDP-ll‘s (PDP-11/70, 
PDP-ll/44> to map the 18-bit Unibus to the 22-bit memo¬ 
ry. 

Unib us 

Unibus is the common I/O bus structure used on a PDP-11 
to connect devices to the CPU. 

Unibus Mapping TRegister 
See UMR. 

UnIt Contro I Block 
See UCB. 

Universal Library 

A universal library is a library file that holds a com¬ 
mon set of files. The librarian utility, LBR, is used 
to create universal libraries and extract and list the 
individual contents. 

UnsoIicited Input 

Unsolicited input is any terminal input that occurs when 
no program has an outstanding read to the terminal or 
has the terminal attached or slaved. 

User File Directory 
See UFD. 

User Identification Code 
See UIC. 

User Mode 

User mode refers to execution of user programs as op¬ 
posed to execution with the RSX executive. 
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VCB 

VCB stands for Volume Control Block. VCB's are the exe¬ 
cutive data structure used by ACP's to hold information 
unique to each mounted volume. 

VFY 

VFY is the RSX utility for checking the integrity of a 
Files-11 disk volume. VFY will also correct many of the 
common errors that can occur with a Files-11 disk. 

Virgin System 

A virgin system is a RSX executive task image file that 
has never been booted or modified using VMR. The recom¬ 
mended practice is to copy the virgin system to another 
file before setting up with VMR and booting. 

Virtual 

The term virtual means from the point-of-vIew of the 
program as opposed to logical which means from the 
p 0 Int-of-View of the system or hardware. 

Virtual Address 

Virtual address is the address within a task and from 
the task's point of view. Virtual addresses are limited 
to 32 KW's (0-177777) and can be dynamically changed 
using PLAS directives to different logical addresses. 

Virtual Block 

Virtual blocks are blocks in a file. These are numbered 
starting from one. 

Virtual Disk 

Virtual disk is a program on the RSX SIG tapes that al¬ 
lows contiguous files to be treated as disks. 

Virtual Terminal 

Virtual terminal means a device that functions as a ter¬ 
minal but is not associated with hardware. Instead a 
program acts as the terminal keyboard and screen. 

VMR 

VMR is the RSX utility for setting up the initial state 
of an RSX system when it is booted. VMR commands are 
identical to MCR, except where MCR operates on the data 
structures in pool, VMR operates on a disk file. 

Volume 

Volume is the largest logical unit of the file structure 
and is equivalent to a disk pack. Volumes are then bro¬ 
ken down into files. 
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Volume Control Block 
See VCB. 


Walt State 

Wait state refers to a task which is active but not com¬ 
peting for the CPU. The task is waiting on some event 
or has its execution suspended. 

W i I d c a r d 

Wildcard is a special character in a file specification 
that matches anything for the field. RSX has two forms 
of wildcards: asterisk <★> for matching all characters 
in the position and percent sign (%> for matching exact¬ 
ly one character. 

Window 

A window is a task's view of a region of memory. 
Windows are controlled by the PLAS directives and can be 
moved under program control to any point in a task's re¬ 
gions. 

Window Block 

Window block is the RSX executive structure used to map 
virtual blocks in a file to the actual logical (physi- 
cal)diskblocks. 


XDT is a part of the RSX executive for debugging of exe¬ 
cutive code. XDT uses a subset of DDT commands. From 
the system console, a programmer can set breakpoints in 
the executive, examine and modify locations, and step 
the execution of the executive. When in XDT mode, the 
executive does not process any normal activity. 


ZAP is a RSX utility with ODT-like commands for examina¬ 
tion and modification of disk files. ZAP has speciaT 
features to easy use with task image files. 


BRU Sorting Bug - A Wrapup 

Carl T. Mickelson 

Goodyear Aerospace Corp 
D470/G3 

1210 Massi I I on Rd. 

Akron, Ohio 44315 
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In an SPR submitted to DEC in May, and published in 
the Mu Iti-Tasker in July 82, I outlined a bug-fix to the 
LBNORD module of BRU. The last issue of the 
Multi-Tasker contained a followup article in which I 
presented a correction to LBNORD to stack the larger 
partition of the sort list rather than only the left 
half as originally distributed by DEC. 

This article is written to correct an error in the 
patches that appeared in that article. Following are 
the corrected patches - note that only one instruction 
has changed from that published earlier. Also, the 
checksum for the LBNORD.POB patch object module is 
changed by the corrected instruction. 

PAT 

LBN0RD.0BJ;2=LBN0RD.0BJ;1/CS:10755,LBNORD.POB;1/CS:33041 


.IDENT /01.2/ 
.=.BLK.+436 

DEC $QSTAK+200.<R5) 

.IDENT /01.3/ 
.=.BLK.+12 
I: .BLKW 1 

J: .BLKW 1 

ISTACK: .BLKW 1 

JSTACK: .BLKW 1 

.=.BLK.+200 
LOOP: 

.=.BLK.+362 

JSR PC,PAT013 

NOP 


.=.BLK. 


The patch for V4.0 given here is slightly different 
in patch locations than the V3.2 patch due to other 
changes DEC made in the baseline version for V4.0. 
Since we are still running V3.2, I have not been able to 
try this patch on a V4.0 BRU. 


.TITLE LBNURD 

; MODIFICATION: 

; 01.2 -- 
1982) 

sil.17.9 

CORP. 


; FOR V3.2 BRU 

FIX SORT LOGIC ERROR IN LBNORD <21 MAY 
THIS IS PART OF THE REAL FIX FOR 
C. T. MICKELSON, GOODYEAR AEROSPACE 
AKRON, OHIO 44315 (216) 796 - 2388 


.PSECT $$PAT 

PATOIS: 

MOV I,R0 

ADD RO,RO 

SUB ISTACK,RO 

CMP JSTACK,RO 

BLE 10$ ; This instruction was BGE 10$ 

MOV $QSTAK-2(R5>,$QS1AK(R5> 

RTS PC 

10 $: 

TST (SP>+ jCLEAN UP STACK 

MOV $QSTAK+198.(R5>,$QSTAK+200.(R5> 

MOV I,R0 

DEC RO 

MOV R0,$QSTAK+198.<R5> 

ADD 2,R0 

MOV R0,$QSTAK(R5> 

JMP LOOP 


STACKING 

ALWAYS 

BUT MAY 

CORP. 


01.3 -- FINISH CORRECTION TO QUICKSORT BY 

LARGER PARTITION OF LIST RATHER THAN 

THE LEFT PARTITION THIS ELIMINATES 
POSSIBILITY OF A STACK OVERFLOW ERROR 

MAKE PAST BRU TAPES INCOMPATIBLE. 

C. T. MICKELSON, GOODYEAR AEROSPACE 

AKRON, OHIO 44315 (216) 796 - 2388 


.PSECT 
.BLK.=. 


.END 


.TITLE LBNORD 

; MODIFICATION: 

• 01.3 -- 

1982 ) 

sil. 17.9 


; FOR V4.0 BRU 

FIX SORT LOGIC ERROR IN LBNORD (21 MAY 
THIS IS PART OF THE REAL FIX FOR 
C. T. MICKELSON, GOODYEAR AEROSPACE 
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CORP. 


STACKING 

ALWAYS 

BUT MAY 

CORP. 


AKRON, OHIO 44315 <216> 796 - 2388 

ALSO, REMOVE “FIX" OF 5.1.17.9 

01.4 -- FINISH CORRECTION TO QUICKSORT BY 

LARGER PARTITION OF LIST RATHER THAN 

THE LEFT PARTITION THIS ELIMINATES 
POSSIBILITY OF A STACK OVERFLOW ERROR 

MAKE PAST BRU TAPES INCOMPATIBLE. 

C. T. MICKELSON, GOODYEAR AEROSPACE 

AKRON, OHIO 44315 (216) 796 - 2388 


.PSECT 
.BLK. = . 


.IDENT /01.3/ 

.=.BLK.+56 

MOV 20.,R2 ;Remove IX" of 5.1.17.9 

.=.BLK.+472 

DEC $QSTAK+200.(R5> 

.IDENT /01.4/ 

.=.BLK.+12 
I: .BLKW 1 

J: .BLKW 1 

ISTACK: .BLKW 1 

JSTACK: .BLKW I 

.=.BLK.+234 
LOOP: 

.=,BLK.+416 

JSR PC,PAT013 

NOP 

.=.BLK. 

.PSECT $$PAT 

PATOIS: 

MOV I,RO 

ADD RO,RO 

SUB ISTACK,RO 

CMP JSTACK,RO 

BLE 10$ ; This instruction was BGE 10$ 

MOV $QSTAK-2(R5>,$QSTAK(R5> 

RTS PC 

10 $: 

TST <SP>+ -.CLEAN UP STACK 


MOV $QSTAK+198.(R5>,$QSTAK+200.<R5> 

MOV I,RO 

DEC RO 

MOV R0,$QSTAK+198.<R5> 

ADD 2,R0 

MOV R0,$QSTAK(R5> 

JMP LOOP 

.END 

I would now like to turn to a discussion of the 
compatibility problem that was introduced into BRU when 
SPR Article 5.1.17.9 was published. The following ob¬ 
servations can be made about the operation of LBNORD as 
distributed by DEC: 

1. Given an "unlimited length" stack, the algor¬ 
ithm as distributed will always sort a list of 
retrieval pointers. Proper performance of the 
algorithm is assured regardless of which parti¬ 
tion (right or left, larger or smaller) is 
pushed onto the stack, so long as the stack 
does not overflow! This is true due to the 
fact that during each Iteration of the algor¬ 
ithm, after a pivot element has been properly 
positioned, all elements to its left are less 
than, and all elements to its right are greater 
than the pivot. Once the pivot Is properly lo¬ 
cated, the stack is used simply to remember the 
upper and lower boundaries of one list parti¬ 
tion while the other list partition is complet¬ 
ed. Stacking the "wrong" partition (read left 
side only in DEC's distributed version) has no 
effect on which partitions are generated. 
Stacking the "wrong" partition only effects the 
order in which partitions of the list are gen¬ 
erated. Therefore a true sort is maintained. 
The only reason to stack the larger partition 
is to guarantee that the deepest stack penetra¬ 
tion is limited to log base 2 of the list 
length (or 10(10) for BRU). 

2. The effect of the "typographical" error in the 
original version of LBNORD on the ordering of 
data on tape is a little more difficult to 
understand. This error was originally dis¬ 
cussed in the July Mu Iti-Tasker. Briefly sum¬ 
marized there is a flaw in the distributed ver¬ 
sion of LBNORD when modifying the partition 
stack when the pivot Index reaches the right 
end of a partition. The algorithm intends that 
the value I-l, designating the upper bound of 
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the left list partition, be saved on the stack. 
The implementation saves the value of I, and 
decrements a location in memory 50 words away 
from the location in which I was stored! This 
location is in the upper half of the stack of 
right end indices for saved list partitions. 
The failure to properly decrement the value of 
I simply includes a previously positioned pivot 
element in the list partition placed on the 
stack. However, it is known that all elements 
to the left of this point are already less than 
the included pivot element. Therefore, includ¬ 
ing the pivot element in the list partition 
will not change the final sorted order of the 
list. The more serious flaw is decrementing 
the wrong word in the stack. If the stack 
never reachs 50 levels deep, no active element 
in the right end index stack will be changed, 
so the list will still be sorted properly. 
Fortunately, for a sufficiently "out-of-order" 
list (see discussion below) the frequency of 
occurrence of such a deep stack is rare. 

3. The distributed version of LBNORD makes a 

pre-sort pass over the list of retrieval po¬ 
inters to determine if the pointers are suffi¬ 
ciently "out-of-order" to warrant sorting. The 
initial "out-of-order" count used to make this 
sufficiency decision was 20(10). The recommen¬ 
dation of SPR 5.1.17.9 is to raise this count 
to 40(10) or higher if stack overflows are 
still encountered, (i.e. the stack is not "un¬ 
limited" enough for the particular list of re¬ 
trieval pointers encountered by BRU) . The ef¬ 
fect of this change is to place more sets of 
saved data, (those that satisfy 20 <= 

"out-of-order" count <= 40) on tape based upon 
unsorted retrieval pointers. If read back with 
a version of BRU using a different 
"out-of-order" count, proper restoration of 
data cannot be guaranteed. This is because a 
different "out-of-order" count version of BRU 
will sort retrieval pointers for some sets of 
data that were not sorted when written to tape. 

4. 4. The patches provided in this article will 
not change the order of data written on tape. 
The patches simply prevent stack overflow by 
limiting stack growth to the theoretical maxi¬ 
mum for quick-sort. 
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There is unfortunately one additional complication 
in this analysis. This is due to the method used in 
dec's version of LBNORD to perform exchanges of retriev¬ 
al pointers within the sorted list. Each retrieval po¬ 
inter in the list is comprised of five words. When an 
exchange of pointers is to be performed, one pointer (5 
words) is stored on top of the stack whi le the second 
pointer is moved into the space occupied by the first. 
Finally, the saved pointer is moved to the space occu¬ 
pied by the second, completing the exchange. 

This use of the stack is perfectly acceptable for a 
BOUNDED stack with at least five additional words for 
the temporary data, but due to the organization of the 
stack in memory, and the nature of DEC’S implementation 
of quick-sort, the stack depth can reach or exceed 
96(10). When this occurs, moving a retrieval pointer 
onto the stack will destroy up to five words of the sec¬ 
ond half of the stack. However, the distributed version 
of LBNORD does not detect stack overflow until the stack 
depth exceeds 100(10). Therefore it is possible to cor¬ 
rupt the stack without overflowing it! This occurrence 
should be Just about as rare as the stack overflow in 
sort error treated in SPR Article 5.1.17.9. In fact, if 
this type of corruption does occur, it is likely that 
BRU will odd address trap or violate memory protection 
and crash. This was probably the mechanism that caused 
BRU to crash last May while saving our disc, and led to 
my discovering the typographical error documented and 
patched in the July Mu 11i-Tasker. 

In summary, a version of BRU with a given 
"out-of-order" count, and with the patches provided here 
applied should be able to restore most any BRU tape suc¬ 
cessfully written with a version of BRU having the same 
"out-of-order" count. This, coupled with the fact that 
it is now impossible to overflow the stack, can solve 
the incompatibility problems of BRU tapes (between V3.2 
and V4.0) by using a universal "out-of-order" count. 
The value 20(10) is suggested, as this is probably the 
most widely used due to its initial distribution. 


EDITORS NOTE 

After having received Carl's article, and Just as I 
was about to send this issue to the DECUS office for 
printing I received the following from Carl. 

Enclosed is a copy of DEC's response to my last BRU 
LBNORD SPR. It effectively confirms my solution to the 
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sort module problems in BRU that have existed for so 
long. 

The DECUS Atlanta patches referred to in this DEC 
response were discussed in my Sept/Oct 82 Mu Iti-Tasker 
article. Regardin the availability of future correc¬ 
tions for BRU, I have been told by the BRU maintainer 
that V3.2 BRU will no longer receive published changes. 
Thus we can expect that Software Dispatch Articles 
5.1.17.2 <Feb 80; BRUBITMAP), 5.1.17.16 (Apr, 81; 
SCNDIR), 5.1.17.18 (Jul 81; BEGIN and BRUALLOC), and 
5.1.17.21 (Dec 82; 11 assorted cumulative patches) re¬ 

present all of the known and to be published patches for 
V3.2 BRU. These patches, together with those pubiished 
for LBNORD, represent a version of V3.2 BRU that should 
run very reliably, at least regarding retrieval pointer 
sorting. 

I would like to discuss some of the problems I en¬ 
countered in applying the BACKLB patch published in 
5.1.17.21, Dec 1982. The baseline ★.PAT files were ori¬ 
ginally acquired from the RSX-llM Autopatch E distribu¬ 
tion. Using these patch files as a starting point, the 
new changes were added to BACKLIB.PAT from pages 1-6 of 
the subject article. The following difficulties were 
encountered: 

1. On page 5, at line 260$:, the macro call RESRG 
should read JSR R5,RESRG. 

2. On page 3, after MOV $LAB1+4,-2(R2>, the line 

.=.BLK. is missing from the Autopatch E base¬ 
line file. The checksum /CS:125544 on page 51 
of the patch article is correct for the changed 
patch file, without this .=BLK. line. 

However, without this line, the patches to the 
blank PSECT made for IDENT 1.07 on pages 4 and 
5 are put into the module at the wrong place, 
because, without the line, the assembler's base 
for this PSECT has been lost. Adding the miss¬ 
ing line .=.BLK. after the MOV $LAB+4,-2(R2) 
instruction, places the patchescorrect I y , but 
changes the checksum for the patch file to 
/CS:125764. One wonders whether this particu¬ 
lar published patch was ever applied directly 
to an object module, or whether the patch file 
was developed from source changes only. 

3. Finally, the line .BLK.=. after 

MSGFLG=.BLK.+1576, on page 5 of the patch, 
should read .=.BLK. to preserve the base ad¬ 
dress for the blank PSECT for subsequent 


patches. This does not change the checksum; 
it remains /cs:125764. 


The checksums for the remaining modules and their 
patches are correct as published in the Dec 82 article. 


SPR NUMBER 11-46577A 


PROBLEM STATEMENT: 

The user submitted his solution for the BRU over¬ 
flow problem in the module LBNORD. 


RESPONSE: 

Thank you for the time you spent helping to solve 
this BRU problem. Me basically agree with your last ar¬ 
ticle in the Multitasker, except on one point. BRU vet— 
sion 4.0 does not produce incompatible tapes because we 
have a special flag word at the beginning of the data 
area on the tape. This word is equal to 1 if retrieval 
pointers for the data were sorted, and 0 if the retriev¬ 
al pointers were not sorted. This means that during the 
restore operations, we do not depend on the sort parame¬ 
ter and cna always determine when we have to sort the 
retrieval pointers. The problem appears only when we 
are restoring BRU Version 3.2 tapes. In this case, we 
definitely need to use the same sort parameter during 
the backup and restore operations. 

The articles in the AUGUST 1980 Software Dispatch, 
and one that we distributed at Decus, represent a possi¬ 
ble solution to the reported problem. Of course, it is 
not the best possible solution, but it always works. 
This is the main reason we still recommend it to our 
customers as a temporary workaround until we publish a 
new correction which will eliminate this problem. 


RSX-llM to RSX-llM-Plus Migration 


Allen A. Matson 
Bergen Evening Record 
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150 River Street 
Hackensack, NJ 07602 


1.0 REASONS FOR GOING TO M-PLUS 


1.1 Shadow Disk 


Our main reason for migrating from RSX-llM to 
RSX-llM-PLUS was the added capability of what is called 
"shadow disk". Me have been, and still are, developing^ 
several large applications that will be handling vola¬ 
tile and sensative data: an advertising accounts re¬ 
ceivable package, a display advertising layout package, 
and a newspaper circulation package. All of this data 
is changing rapidly from day to day. Some of it, such 
as the ad layout data, is critical to the daily produc¬ 
tion of the newspaper. 

In the newspaper computing world we have a saying: 
"THERE IS NO TOMORROW." In most computing applications 
in the event of disaster it is possible, although not 
desirable, to "do It tomorrow". Getting out payroll a 
day late may be expensive, it may cause alot of discon¬ 
tent, but in the worst case it can be done. Producing 
Tuesday's newspaper on Wednesday, however, simply cannot 
be done. For a newspaper, there is no "tomorrow". 

For applications involved in the production of the 
paper, therefore, data backup is Imperative, and reco¬ 
very in case of disaster, such as a head crash, must be 
nearly instantaneous. Typically, in newspaper applica¬ 
tions, five minutes is considered a maximum recovery 
time. It may be nice in movies about newspapers to have 
someone screaming "Stop the press!", but in real life 
stopping the press is about the last thing you ever want 
to do. To stop the press because the computer has lost 
data necessary to the production of the next pages would 
cost so much that you could buy a complete secondary 
computer with the money. In fact, almost every paper I 
am familiar with has totally redundant computer hardware 
for just that reason. 

What we needed was dual recording of critical data 
on two identical disk packs , so that if a head crash 
occurred, all that would be necessary to recover would 
be to boot up from the second disk. That is what "sha¬ 
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dow recording" is. A complete, up-to-the-second, mirror 
image copy of your disk is maintained on another disk 
mounted on another drive. 

Me briefly considered a transaction log type of 
system, where any updates to files would be logged onto 
a disk or a mag tape. Ihis required a lot of support 
software: each application would have to handle its 
transaction logging, programs would have to be written 
to recover from transaction logs and periodically purge 
them, and so on. Any new application would have to in¬ 
clude support of transaction logging, making all the ap¬ 
plications larger. Me rejected this approach in favor 
of M-PLUS and shadow disk because shadow disk is tran¬ 
sparent to the application and requires no additional 
code. 

A nice side benefit of shadow disk from the viewpo¬ 
int of operations is that it eliminates the need to copy 
the disk you are shadowing; you have a constant, 
on-line copy. 

In our brief experience with shadow disk, we have 
found that it adds little overhead to the system, espe¬ 
cially when you funnel the shadow disk through a separ¬ 
ate controller using a unique AGP. 

Remember, however, that if you have four disks you 
want to shadow, you will need eight disk drives! If the 
ability to recover from a head crash in five minutes 
instead of an hour, or much more (you know what it would 
take at your site) is worth the price of another drive, 
you should consider using M-PLUS shadow disk. 

At THE RECORD we have experimented with combining 
the Virtual Disk package from the RSX SIG tapes with 
shadow disk. This allows us to designate selected sets 
of files that have been assigned to virtual disks, which 
are located on several disk drives, for shadowing on a 
comparable set of virtual disks that have been located 
on a single "shadow" drive. Me have limited the files 
to be shadowed to the critical few, instead of duplicat- 
ing entire disk packs, and have been able to reduce the 
number of drives needed to shadow those files. I will 
be discussing this aspect of shadow disk in a separate 
session Thursday afternoon at 4:30. 
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1.2 Overlapped seeks for disk 


M-Plus supports overlapped seeks for disk. This 
feature allows multiple disk units attached to a single 
controller to perform seeks (head movement) simultane¬ 
ously, although only one data transfer can occur at any 
one time. Most advanced disk controllers support this 
feature, as ours do. Since we anticipated an operations 
environment where up to eight drives might be accessed 
through a single controller, it seemed to us that over¬ 
lapped seeks would be a considerable help to disk 
throughput. 

In our current operations we rarely have more than 
two drives operating through a single controller, and in 
most cases we are operating on Just one drive, so we 
have no concrete data yet on savings through overlapped 
seeks. 


1.3 Supervisor mode libraries 


using a supervisor mode library for File Control Ser¬ 
vices (FCS). That makes those commonly used programs 
smaller, and for the larger ones that require a lot of 
overlaying under RSX-llM, allows DLC to reduce the over¬ 
laying, thus reducing the number of overlay calls from 
disk. In sum, the utilities are smaller and run faster. 
The option of building FCSFSL utilities is offered dur¬ 
ing SYSGEN and I advise you to take it. 


1.4 Secondary poo I 


Under RSX-llM we had frequent system crashes when 
we ran out of pool. For you new users, "pool" is a 
space in the executive used by the system as a work area 
to contain data structures such as system lists, control 
blocks, and I/O packets. Every file that is open has a 
file control block in pool; each installed task has a 
task control block; active tasks have task headers in 
pool; each terminal has a user control block, and so 
on. There's a lot of stuff in pool and only a limited 
space in the Exec. When it fills up, the system 
c rashes . 


Available only on 11/70's and 11/44's under M-PLUS, 
supervisor mode libraries are resident libraries that 
double a user task's virtual address space by mapping 
the instruction space of the processor's supervisor 
mode . 

That was a near quote from the Executive Reference 
Manual. For those of you who haven't yet learned to 
speak DEC, let me give a rough translation. A task or 
program under RSX-llM is only allowed to have 32K 
(roughly 32,000) locations of memory to run in because 
the hardware can't count any higher than that. 
Supervisor mode is like a second counter, allowing 
another 32K locations to be used. For a Iittle memory 
overhead in your program and some run time overhead when 
your program has to switch modes to get at the stuff in 
the supervisor mode library, you can double your program 
size. 

That was important to us because we are converting 
a number of programs from an IBM 370 with virtual memory 
to run on our 11/70. Most of them were Just too big to 
run without overlaying and breaking them up into sub¬ 
tasks, with the attendant overhead in increased execu¬ 
tion time. Supervisor mode libraries give us the abili¬ 
ty to build bigger tasks. 

In addition, many of the DEC utilities can be built 


How many of you RSX users have experienced that 
problem? 

Before M-PLUS we tried lots of tricks to get more 
pool or to keep from crashing. We installed the Pool 
Monitor Task from the SIG tapes; we put in patches from 
Jim Downward at KMS Fusion that allowed us to run with 
fewer tasks installed; we put in a patch to the termi¬ 
nal database to reduce the number of SCB's for termi¬ 
nals. Each thing helped a little, then we'd run out of 
pool again as the load increased. 

Under M-PLUS we have yet to come close to running 
out of pool space. One of the main reasons is secondary 
pool. Secondary pool is a memory partition that is out¬ 
side of the Executive, and it can be as large as you 
want. M-PLUS uses it for more permanent or less fre¬ 
quently used data structures, and thus frees up that 
space in primary pool. Task headers, for example, go 
there, so under M-PLUS there is almost no limit to the 
number of tasks you can install. 

We had a pool problem under M; no longer. We come 
up with over 11,000 words of primary pool. We'll run 
out of memory long before we run out of pool. PMl seems 
almost superfluous under MPLUS. But we can (and will) 
buy more memory! and you could never buy more pool. 
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1.5 Directive common 


2.0 TRANSITION PROCESS FROM M TO M+ 


Directive common is another way you get more pool 
space; some of the executive directives are moved into 
a common partition thus freeing up more space in the 
exec. 


1.6 Multi-user tasks 


Our system has lots of users. Me anticipate having 
up to 52 terminals on a single 11/70. That many users 
can fill up memory with tasks awfully fast. M-PLUS al¬ 
lows the building of multi-user tasks, in which a single 
copy of read-only portions of a task is shared by many 
users. Even on our development system, the multi-user 
versions of EDT and PIP have helped reduce checkpointing 
in the system. Me are making some of our appiication 
tasks multi-user also. 


1.7 Multistream batch processing 


Me wanted batch processing so that users could 
schedule long, time-consuming tasks to be done in off 
hours. Batch allows you to do this. In effect you sub¬ 
mit a command fi le to the queue manager Just I ike a 
print Job: SUBMIT MY JOB/AFTER:17:00. Also, when devel¬ 
opment gets really heavy we can ask users to submit Jobs 
to batch streams rather than running them directly, thus 
limiting the number of simultaneous compiles and task 
b ui Ids. 


1.8 Task and user accounting capability 


Me expect our system to overload before long even 
under M-PLUS. Mhen that happens we will be able to use 
the resource accounting facility to determine which 
tasks are overloading the system, and with what kind of 
activity: CPU, disk, QIO's, etc. It is possible we may 
develop a charge-back system to our user departments. 


I would say we had a rough transition, but largely 
because of two factors: first, we elected to migrate at 
exactly the time DEC was discontinuing Version 1.0 and 
starting on Version 2.0. For several months we couldn't 
get either version from them. Finally they delivered 
Version 1.0; about six weeks later, we got Version 2.0. 
Me had barely adjusted to Version 1.0! 

Second, we had all non-DEC disks and disk controll¬ 
ers. It's very hard to SYS6EN a system when you can't 
run any of your disks on it. Me ran our Version 1.0 GEN 
from our RSX-llM 3.2 system, and then GEN'ed our Version 
2.0 using the Version 1.0 system. Before starting the 
GEN, we had to modify SAVE, the DB driver, other utili¬ 
ties and the SYSGEN command files to compensate for our 
foreign controllers. It was frustrating because we 
spent weeks debugging code for the disk sub-system with¬ 
out being able to see the new system at all. Me read 
the manuals and dreamed great dreams; meanwhile we 
couldn't even boot the thing. 

If I were back buying our system in the first place 
I would include at least one standard DEC disk system 
for doing SYSGEN‘s if for no other reason. 

One nice thing is that DEC had included very clear 
instructions on how to GEN a Version 2.0 system from a 
Version 1.0 base -- Just what we needed. They even have 
a special command file for doing it, letting you build 
the Version 2.0 versions of MAC, TKB and IND that you 
need for the GEN on your Version 1.0 system. Me did it 
and it works. In general the Version 2.0 SYSGEN manual 
is much clearer and the SYSGEN procedure is much simpler 
than any I have done before. 

Auto CO nfigure is a new thing DEC has added that el¬ 
iminates the messiest part of a SYSGEN: specifying 
CSR's and vectors for all your hardware. Autoconfigure 
Just goes out there, probes around the system to figure 
out what hardware is attached, and generates alI that 
stuff for you. It then allows you to examine and edit 
the results in case it goofed or left out something it 
couldn't recognize. If you have a system put together 
by DEC with mostly DEC hardware, use autoconfigure; or 
if you know your CSR's and vectors meet their standards, 
use it. Our CSR's and vectors are definitely 
non-standard even for the DEC gear (the system was put 
together by an OEM) and we found it more convenient not 
to use aut 0 configure, so I can't say how it works. 
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3.0 PROBLEMS ENCOUNTERED IN SYSGEN 


3.1 Bug in Building the Executive 


The command file SGNBE.CMD has a bug in it that DEC 
knows about. Mhen the exec finishes task building the 
command file attempts to wait for the cross-reference to 
complete with the statement: 

.IFINS CRF... .WAIT CRF. . . 

For some reason this causes an error message saying 
"SPAWN FAILURE" and the SYSGEN command file aborts. 

The only thing that fails is the indirect command 
file. The task build of RSXllM has worked fine. All 
you really need to do is make sure CRF has finished and 
continue with the GEN. I checked SGNBE.CMD and the only 
remaining executable line was "TK8 ^DRIVERS". So I 
typed that in directly, waiting for it to complete, and 
then re-started the SYSGEN at the next phase after 
"Build the Executive and Drivers". Worked fine. 

You could modify SGNBE.CMD (see note on SYSGEN com¬ 
mand files below under "Hints from our Experience") by 
commenting out the line at fault and replacing it with a 
.PAUSE. When it pauses, Just check active tasks. If 
CRF... is not active, then resume. DEC software sup¬ 
port suggested removing CRF... before starting the 
build of the exec, but that seemed counter-productive to 
me . 


3.2 Getting correct versions of N.P. tasks 


Pay close attention to the NOTE on page 3-63 of the 
SYSGEN manual . If you make any changes to the task 
build files to select options on some of the 
non-pr i ve I eged tasks, and you fail to move them from 
Cl,543 to C3,543 after they are built, you won't get 
your tailored versions of those non-priveIeged tasks 
when you bring up the system. The versions of those 
tasks from the distribution tape are in C3,54D. The 
versions you build, for some reason, go into 11,543. 
When SYSGEN creates SYSVMR.CMD file it specifically in¬ 
stalls non-prive I eged tasks from C3,543 so you get the 
DEC originals, not the ones with the options you so 
carefully chose. DEC should build non-pr i ve I eged tasks 
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into C3,543 if that’s where they expect them to be, and 
I have complained to that effect in an SPR. 


4.0 HELPING THE USERS ADJUST 


Some of these things probably apply equally well to 
new users of RSX-llM Version 4.0. In general the tran¬ 
sition for the users of our system was painless, but not 
without some effort ahead of time and behind the scenes. 


4.1 Getting used to DCL 


For someone coming to M-PLUS from M Version 3.2, 
DCL is something new. We elected to put in DCL as the 
primary Command Line Interpreter (CL I> and to modify the 
task build file (see below) to select the option to 
allow any unrecognized commands to fall through to MCR. 
If you don’t do that, any user of DCL is going to be ex¬ 
tremely annoyed when typing PIP fi IeA-fi I eB/RE elicits 
an "UNRECOGNIZED COMMAND" message. You can’t get di¬ 
rectly at anything through DCL, not even PIP, unless you 
enable the fa I I-through-to-MCR option in the task build. 

Overall falling through to MCR works fine; people 
used to MCR Just go on using it as they always did and 
never know DCL is there until they get around to reading 
the new manuals. Almost. 

There are a few problem spots where MCR and DCL use 
the same command, as in SET, MOU, MAC, FOR, and INS. A 
user enters a fami I iar command I ike "MAC FILE^FILE" and 
is given the error message: 

MACRO — Extraneous input 
MAC FILE=FILE 


That 
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comp 

lain 
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If they’re going to do a lot of that sort of thing, 
they can set their terminal to MCR as primary CLI with 
SET TERMINAL MCR. In general, SET TERMINAL MCR and SET 
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/DCL=TI: should be the first two new commands you teach 

your users if DCL is in your system. 

4.2 Command file execution 


If a terminal is running under DCL many old command 
files won't work if they use MCR commands like "MAC 
FILE,FILE/-SP=FILE" because "MACRO" is a DCL command ex¬ 
pecting DCL syntax. I happen to like DCL, so what I do 
is put this into my command files: 

.setf DCL 

.if <CL I > = "DCL" .sett DCL 
.ift DCL SET TERM MCR 


contents of old command file 

.ift DCL SET /DCL=TI: 

That could be more generalized if you plan on multiple 


.sett MCR 

.enable substitution 

.sets CLI <CLI> ! Save starting CL I ! 

.if CLI NE "MCR" .setf MCR 

.iff MCR MCR SET /MCR=TI: lAssumes MCR command in all 


.iff MCR SET /•CLI'=TI: ! Restore starting CLI ! 


4.3 Hints to KMS CCL users 


Me still use CCL. It works fine. Me have three 
commandline interpreters: DCL, MCR, and CCL. DCL comes 
first; any unrecognized commands fall through to MCR; 
finally, CCL is installed as CA. (catch-all) to handle 
anything MCR does not know. All I did was to rebuild 
CCL.TSK on the new system, and since CCL is not prive- 
leged even that was probably unnecessary. None of the 
Jim Downward patches to system routines were made; most 
of them exist in MPLUS as distributed. One Downward 
patch to MCR we miss was the one that forced it to pass 
everything to CCL (instead of kicking out things like 
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"?" and "LI"). Mhen we want to add a new command it is 
still ever so much easier to edit two or three lines 
into SYSCCL.CCL than to master the complex syntax re¬ 
quired to build a DCL command table entry, edit the 
file, assemble it, and double task build DCL! 

The /CMD parameter to RUN is not exactly like the 
old KMS /PRM parameter: it expects the task name in the 
first four characters. In other words, it clobbers the 
first four characters you pass. You must say: 

RUN $MAC/CMD="MAC FILE=FILE" instead of 
RUN $MAC/PRM="FILE=FILE" 

The CMD parameter does not exist for INSTALL, as 
PRM did in the KMS mods. One strange annoyance is that 
you cannot pass parameters to an installed task from the 


RUN command using CMD; to use RUN/CMD the task must be 
n on-in staI led. 


4.4 New Introduction manual 


The Introduction To RSX-llM-PLUS book with accompa¬ 
nying files in L200,1] are a great training aid for new 
users. I did find some of the examples in the book did 
not work; some files used in the text were missing, but 
were easy to provide. Mostly they were one-line text 
files used to illustrate several commands like TYPE and 
PRINT. Nothing major was missing. I suggest you run 
thru the book yourself before handing it to a new user, 
and fix the things that don't work. Even your old hands 
should work thru this because they will learn DCL and 
other stuff they probably never knew or have forgotten 
(e.g. EDT line edit mode for people who always use key¬ 
pad). 

One outright error: the manual says the EDT com¬ 
mand "T LAST" types the last line of a file; in fact it 
types the last Iine referenced. Ihe command should be 
"T END-1" . 


4.5 Queue Manager and Error Logger 

The Queue Manager and Error Logger commands have 
changed entirely from anything you ever knew. God knows 
they needed it, but be warned and spend some time look¬ 
ing through the documentation before turning the system 
loose on your users. You may want to write some memos 
to frequent users and computer operations personnel, or 
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hold some re--fcraining classes. At least alert them to 
the excellent HELP files and how to find them. 

If you have any command files that used to make 
error report generation easier , throw them out. 
They'll be useless. Be prepared to rewrite, and to find 
that it is easier this time. I wrote a file called 
ERRORS.CMO for our operators to use <it will be in 
C333,1003 on the SIG tape) that walks them through most 
of the options. 

10 

The canned report option for the error log REPORT 
GENERATOR did not work. You are supposed to be able to 
enter: 

RPT /RE:DAY 

to get a full summary report on all today's errors, for 
example. It bombs. My ERRORS.CMD file could not make 
use of this switch, unfortunately. I have SPR'ed this. 


5.0 HINTS FROM OUR EXPERIENCE 


5.1 Multi-path access to disks 


Setting up procedures for proper handling of 
dual-ported disks, disks that in addition are accessible 
from two or three CPU's simultaneously, was very com¬ 
plex. Me have three CPU's, three controllers, and six 
drives. The disks are each connected to two of the 
three controllers, and all three controllers are con¬ 
nected to all three CPU's. There are two paths to each 
disk f rom each CPU. 

M-PLUS allows you to specify disk drives as 
dual-ported. Since that is what we have physically it 
seemed to make sense to tell the software about it. It 
took us weeks to find out ail the things that could go 
wrong. He found no actual bugs in the software. Just 
mass confusion for us as users. 

One rule of thumb: DON'T LIE TO THE SYSTEM. If 
you SAY there are two paths to a disk there damn well 
better BE two paths. You see, we have this nice switch 
panel that can put individual ports on a controller off¬ 
line... Hell, if the second path for 062: is switched 
offline, and you try to MOUNT 0B2:, mount will time out. 
If you're booting from 0B2:, tasks wilt start getting 


load failures in STARTUP right after CON ONLINE ALL is 
executed (more on the CON tasks below). 

He also found (with CDC drives and SI controllers) 
that dismounting a pack on one CPU could knock it off¬ 
line for another CPU as well. He had one CPU booted 
from DB5:. A user on a second CPU mounted DB5:/N0HRITE 
(that's a new switch on MOUNT that is very useful), and 
when he was done, he dismounted DBS: like a good user 
should. Bang! down goes the first CPU. For some rea¬ 
son, even though our drives look I ike RP04's to RSX, the 
dismount command is trying to unload the disk! And for 
some reason the disk seems to recognize it even though 
it can't be unloaded from software. (Could be a 
hardware bug.) 

He finally discovered that, to be safe, we should 
mount disks with a new switch, /L0CK=N, which sets the 
default for dismount to "no unload". That way users 
don't have to remember to use DM0 DBn:/L0CK=N. He set 
up a M0UNT.CMD command file and have everyone use it to 
mount a disk so the right switches are always used. 

Another switch useful in multi-path situations is 
/LRU=0. Mhenever we mount a disk /NOMRITE we also add 
/LRU=0, which instructs RSX not to cache directories in 
memory but to always read from the disk. That may sound 
inefficient, but when we mount a disk /NOMRITE it is 
usually because it is mounted for writing from another 
system. Directories can get strangely out of sync when 
one system is writing to a directory and another thinks 
it has the directory cached in memory! 

Hhat we really need is a mechanism that completely 


prevents a disk being mounted for writing from two sys¬ 
tems at once. He have done that, of course, and the re¬ 
sult is hundreds of multiply allocated blocks as each 
system blithly writes using its own copy of the bitmap 
of free blocks. One useless disk and lots of grouchy 
users. Me are currently working on some mods to MOU and 
SAV to accomplish this. 


5.2 CON, the System Reconfiguration task 


The System Reconfiguration task is both an enormous 
boon and a colossal pain. This task enables you to 
place devices in your configuration either on or offline 
by software command: CONFIGURE OFFLINE DBO:, for exam¬ 
ple. You can also display and even change CSR's and 
vectors! This affords great flexibility. But there is 
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a whole new command set to learn* 

The pain comes from what I said above: DON'T LIE 
TO THE SYSTEM. RSX-llM users are used to being able to 
do peculiar things like spinning down one disk and spin¬ 
ning up another in its place without dismounting it from 
the system. M-PLUS won't let you do that; the minute 
you touch the button it dismounts the drive automatical¬ 
ly. This particular protection is, I suppose, good. 
But sometimes I want to lie to the system! Like when I 

blow a home block on an otherwise good disk and want to 
recover its files. I've kept a Version 3.2 pack around 
just so I can play that game. 

A related difference is the fact that under M-PLUS 
any access to mag tape requires that the tape be mount¬ 
ed. To initialize a tape you can't Just allocate your¬ 
self the drive and initialize; you allocate it, MOUNT 
it /FOREIGN , and then initialize. Same with 6RU and 
other utilities that used to access unmounted tapes and 
disks under RSX-llM; no more, you have to MOUNT 
/FOREIGN. 

In general M-PLUS forces you to be more careful 
about what you do with the hardware, and to tell the 
system using CON before you do it. If we are going to 
switch an access path to disk offline, we first must CON 
it OFFLINE. Makes sense, but at first it creates 
strange situations for someone used to M. 


5.3 Task Build options 


Before building non-priviIeged tasks, I recommend 
you search thru all xxxBLO.BLD files in [1,20D for all 
the GBLPAT and GBLDEF lines to see for yourself what op¬ 
tions you have in task building the various utilities. 
These are command files used by SYSGEN to create 
xxxBLD.CMD files in Ql,243 for the related task builds. 
For example, PIPBLD.BLO contains switches to select op¬ 
tions for PIP. 

There is a point where SYSGEN pauses after creating 
the command files in Cl,243 and asks if you want to edit 
any of them, and you could wait untiI then and then do 
your editing. However, if you re-run SYSGEN for any re¬ 
ason you'll have to repeat the editing. In addition, 
you can, if you wish, build three versions of many util¬ 
ities, one regular (overlaid), one using FCSRES, and one 
using FCSFSL. Then you have to edit three command files 
in Cl,243. If you edit the xxxBLD.BLD files in Cl,203 


before starting the non-priviIeged task part of SYSGEN, 
then your options will automatically be included in all 
three versions every time you do a GEN. 


5.3.1 PIP 


For example, PIP is advertised as having the option 
to preserve creation date on copies, but nowhere does it 
tell you that you must edit a global in the PIPBLD.BLD 
to obtain this option. 


5.3.2 INDIRECT 


The Indirect Command processor also has nifty op¬ 
tions. For example, you can have it default to the sys¬ 
tem UIC (or another you designate) if the command file 
is not found in the user's UIC; once again, however, 
you must edit the Build file to get this. IND is now 
called ICM Just to confuse you. 


5.3.3 DCL 


DCL has a couple of options, most useful of which 
is allowing unrecognized commands to fall through to 
MCR. Edit Cl,203DCLBLD.BLD to get it. 


5.3.4 Other tasks with options 


Tasks 

I found 

having 

build file options: 


DMP 

CMP 

AT. 

LPP MAC PIP 

PRT 

QCL 





QMG 

RMD 

SHA 

TKB ACN BYE 

HEL 

LBR 





RPT 

SAV 

DCL 
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6.0 MISCELLANEOUS COMMENTS 


The ability to broadcast to users by name is nifty: 
finds them even on multiple terminals. 

The sample DTR reports for Resource Accounting are 
excellent tools for producing your own customized re¬ 
ports. All of the accounting records are now accesible 
through Datatrieve. 

In general, Mplus is easier to manage for an unso¬ 
phisticated user because it translates more of what you 
need to know into human-readable form. 

Be aware that under M-PLUS a task named "...XXX" 
NEVER RUNS; it is a prototype task only. When TTO runs 
it by saying "XXX", it gets a task called "XXXTO". If 
you have any command files that try to do ".WAIT ...XXX" 
they will no longer work. Such tasks are not intended 
for mu Iti-1ermina I use and should be installed with task 
names not in the form "...XXX". 

SIG programs we built under MPLUS (versions on SIG 
tape): SRD (multiuser, non-overI aid>, lECO, UIC, LIST, 
GREP, COOKIE, RNO, DOC, DUNGEON, C(XCC>, PREDAY, TYPE 
(renamed TIPE), TREK, TCP, BRUDIR, SRDCMD (CMD>, ADVENT, 
RMC, LUT, USERMN, TRUNC, RATFOR, PACMAN. Most required 
no modification, only a few required other than minor 
mods to the build files. 

The HELP files on Version 2.0 are fantastic, in 
some cases more accurate than the manuals. I wrote 
three TECO macros, HDX, HFL, EDH, and TEH (all with both 
TES and TEC extensions), to help me step through all of 
them and index what is there. See C333,1003 on the cur¬ 
rent RSX tape. (The text of this handout -- possibly 
with updates after 15-0CT-82 -- will be there, too as 
M2MPTALK.DOC.) 


The Night of the SIG Tape 


Roger Jenkins 

Wycliffe Bible Translators 
Huntington Beach, CA 92647 


At the Fall Anaheim Symposium, several of us were 
standing around waiting for others to show up before we 
left to create the SIG tape. Ralph Stamerjohn walked by 
and made the suggestion that we should place an article 
in the MULTITASKER describing the work that goes into 

the SIG tape collection. This article is a result of 
that suggestion. 

At the Spring 1982 Atlanta DECUS Symosium, I had 
approached Jim Neeland, RSX SIG Tape Coordinator, and 
had offered our site as a collection point for the Fall 
Anaheim Symposium. Our site is about 12 miles from the 
Disneyland Hotel, so it seemed like it would be a con¬ 
venient point from which to create the SIG tape. Jim 
accepted my offer, so Tuesday night around 10:00 PM we 
loaded seven people and a box of 30 tapes into two small 
cars and drove to our site for a marathon tape copy ses¬ 
sion. 

The first step (after the usual site inspection 
every programmer performs when he walks into a new ma¬ 
chine room) was to prepare a scratch disk onto which the 
contents of all of the tapes would be placed. Me have 
three RP06 equivalent drives and two tape drives. I had 
requested exclusive use of the machine, so we had plenty 
of resources. 

Next we had to load several utility programs: TECO 
(mine was not up to date), version 3.2 BRU, TPC, FFL and 
perhaps there were others that were necessary to create 
the SIG tape. 

Before long there was quite a flurry of activity. 
Charles Goodpasture and Vince Perriello were carefully 
checking tapes and release forms to make sure that each 
tape had a release form and that it was signed. Jim 
Neeland and Glenn Everhart were copying the software 
from tape to disk, John Osudar was mounting tapes left 
and right and Tony Scandora was the "scribe" recording 
the directories into which each tape was placed. 

I asked Jim, who was also coordinating the overall 
activity, how he determined which UIC the contents of a 
tape went into. Basicily there is a set of 4 rules: 

1. If the person submitted a tape last year, his 
data went into the same UIC as last year. 

2. Each LUG is assigned a group number, and new 
submissions are placed into subsequently num¬ 
bered member UICs within the LUG's group. 
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3. If a person is not part of a LUG but is close 
enough geographically to be a part of one, his 
submission may be included as part of the LUG 
group . 

4. For every one else, they are placed into a com¬ 
mon group with each submission getting its own 
member number. 

If the tape UIC was wrong, then it was copied into the 
right UIC when possible. At least one tape was in BRU 
format and we wanted to place the files in a different 
UIC than they were in on the tape. This involved copy¬ 
ing them to the same UIC as on the tape, but that UIC on 
the disk already had files in it. So first the files on 
the disk were renamed to a different UIC then the tape 
was copied and those files renamed to the right UIC then 
the original files were renamed back in to the correct 
UIC. Now you know why we were here until 6 AM. 

The copy process itself was no simple task. Even 
if the submission form told the tape format and was cor¬ 
rect, then several tries might be necessary. For exam¬ 
ple, if the submitter failed to specify whether 3.2 BRU 
or 4.0 BRU was used, then one BRU would have to be tried 
and if it didn't work the other would be tried. A lot 
of intuition and guess work was required if the format 
was not specified. Me would try FLX, ANSII PIP, 3.2 
BRU, 4.0 BRU and even DMP! Jim tells of one time when a 
format even turned out to be RMSRST. ("It mounted like 
an ANSII tape but PIP wouldn’t read it!") 

After several of the tapes had been loaded to disk 
and all of the submission forms had been checked, 
Charles and Vince switched to mounting the tapes (they 
did the "reel" work). Then John began the laborious 
task of reading alI of the README files and summarizing 
them. For each UIC, John created a file from README 
info containing a one line description of each program. 
Then these files were sorted in UIC order and merged to 
form the final SIG tape contents summary. This data was 
then edited further and placed in C300,1JRSXF82TPE.DOC. 

Hhen the disk was finally ready, we made copies of 
the preliminary tape for each of us. Jim then took that 
copy back to his site to prepare the final tape. He 
will notify the members of the distribution tree by mail 
when the tape is ready. It is then the responsibility 
of each LUG librarian on the tree to contact his parent 
node to get a copy of the tape. If for some reason his 
parent node can't him a copy of the tape, he should con¬ 
tact his grandparent node. 


The tape copy team had several suggestions for sub¬ 
mitters that would make the tape copy Job easier: 

1. Submitters from LUGs should get a UIC number 
from the LUG librarian. 

2. If you have to use a specific UIC, use one 
below C300,l] to avoid colisions with other 
submissions that may already be on the disk 
when your tape is copied to disk. Label the 
tape and submission form with the UIC you are 
using. 

3. FLX is the easiest format to work with for 
small submissions and especially when you don't 
know a UIC number. If you use BRU, specify the 
backup set name(s) and the UIC(s) used. 

4. Always include a README.1ST (not README.DOC, 
README1ST.DOC, etc.) The README.1ST should be a 
summary of the programs in the UIC (one or two 
lines per program), not the main documentation. 

5. Be sure to fill out the submission form cor¬ 
rectly. Tell the truth about the tape format 
and density. 

I think that the SIG tape is one of the most su- 
cessful "products" of the RSX SIG. I know that my site 
has benifitted greatly from it. Me all owe our appreci¬ 
ation not only to those who have contributed to it but 
also to Jim Neeland and the others who have worked long, 
hard and late hours to put the tape together over the 
years. 


Unlimited Keywords in TPARS 

Ken Cross 

Perceptics Corporation 
221B Clark Street 
Knoxvi I Ie, IN 37921 

TPARS is one of the neatest packages that DEC has 
made available to users. Those unfamiliar with it 
should check it out in the I/O Operations Manual. It is 
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a llitle strange at first, but once you get the hang of 
it, you find many useful applications. 

We have used TPARS to develop the operator inter¬ 
face for a Falcon that controls the image processing 
system we have developed. It provides very powerful 
command syntax structures, but was restricted to 64 key¬ 
words. I had run into this limitation on other projects 
and got around it in very complicated ways in my appli¬ 
cation program. This time I decided to fix it right. 

The fix involves moving the address of the keyword 
strings into the “extension” word of the transition 
tables. It doesn't take any more memory than before and 
simplifies the processing. All keywords have a 200 
(octal) in the TYPE byte. An unlimited number of key¬ 
words can be used. 

The only drawback of this fix is the fact that it 
is not compatible with the standard TPARS. All programs 
using TPARS must be reassembled and built again. 

The fix involves changing the TRAN$ macro and a 
smalI patch to the .TPARS routine. You may want to keep 
them separate from the originals to maintain compatibil¬ 
ity. 

The patch to TRAN$ can be done by extracting the 
macro from RSXMAC.SML and using a SLP correction fi le: 


> LBR TRANSORIG.MAC = LB:C1,URSXMAC.SML/EX:TRAN$ 

> SLP @TRANS.C0R 


TRANS.COR contents: 


TRANS.MAC=TRANSORIG.MAC 

-29,37 


.MACRO 

$$$TYP 

.BYTE 

200 

.ENDM 

$$$TYP 

$$$KEY = 

$$$KEY + 1 

$$$FLG = 

$$$FLG ! 1 

.MACRO 

$$$EXT 

.WORD 

$$$TMP 

.ENDM 

$$$EXT 


/ 

The revised module could then replace the original, 
if desired: 
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>LBR LB:Cl,IDRSXMAC.SML = TRANS.MAC/RP 

The patch to TPARS changes five words. The sim¬ 
plest way to do this is to use ZAP. 


>LBR TP ARS. OB J=LB: Cl , nSYSL IB/EX: .TPARS 
>ZAP 

ZAP>TPARS.OBJ/AB 


LOCATION 

CHANGE 

TO 

2:202/ 

042700 

16500 

2:204/ 

177700 

1 

2:206/ 

006300 

240 

2:210/ 

061600 

240 

2:212/ 

011000 

240 

1 :16/ 

146400 

146401 


The last word changes the version from V0122 to 
V0122A. The revised module could then replace the ori¬ 
ginal, if desired: 

>LBR LB:Cl,nSYSLIB/RP = TPARS 


CCL Gan Help Protect Your System 

El Ieze r May 

Tad Iran Electronics Ltd./Systems Division 
P.O. BOX 267 
Holon, Israel 

PROBLEM: 

A malicious user who has access to the computer and 
disks (beyond my control to change this) and gets into 
the system files after stealing "privilege status" (gen¬ 
erally by aborting the startup procedure). 


HISTORICAL BACKGROUND TO CCL ON MY SYSTEM 

After writing a primitive CCL processor and trying 
a few CCL's from DECUS RSX tapes, I found the version 
from James Downward of KMS FUSION, INC. to be excel- 
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lent. With its help i began buildin a system of EN¬ 
GLISH, easily understood commands for my users. (Down 
with non-descipt acronyms followed by esoteric 
switches!) Next I decided to use the capability of "fly¬ 
ing install", run, and remove in order to save pool 
space for tasks that need not be installed permanently. 
This worked fine for me but the install failed for my 
n 0 n-pr i Vi I edged users. To solve this, I installed a 
simple fix to CCL to turn on the priviledge bit if the 
command being processed is found in SYSCCL.CCL and to 
restore the status upon completion. In effect this par¬ 
allels the use of priviledged tasks by non-priviIedged 
users if such tasks are installed. RSX checks the pri¬ 
viledge at the time of install and not run. Therefore 
the system manager can control which priviledged tasks 
are safe for the users to use. Similarly, this allows 
the system manager control over which commands the user 
can use in priviledged mode from the extended system 
commands, i.e., SYSCCL.CCL. 


PROTECTING THE SYSTEM 

The first thing that must be done is to assign ap¬ 
propriate access permissions to all system files, i.e., 
no permission to delete or modify. The users may either 
execute or read as is appropriate. Do not forget files 
i n i:0,0] . 

The next problem is to eliminate his access to pri¬ 
viledge mode whereby he can overcome the file protec¬ 
tions. As a further safeguard in case he does somehow 
find an unguarded terminal in priviledge mode, hide ACNT 
with a different name somewhere obscure in the system. 
This is of vital importance. The first thing my mali¬ 
cious user did was to get a listing of all user accounts 
and passwords. The two methods he used were dumping the 
file with the account information and ACNT. 

The final problem deals with protecting against 
privileged access at the time of booting the system. I 
first after making a copy of the system disk (the devel¬ 
opment of such protections will frequently render the 
disk unusable and must be restored) VMRed RSXllM to 
start off TTO as non-privi Iedged and in a non-privi I eged 
UIC. Also redefine CO to the null device. This further 
protectsagainst an abort attempt during "wake up". The 
normal processing commands in C1,2DSTARTUP are separated 
into different files with a complex chain of indirect 
command file chaining between them. The first command 
in STARTUP initiates a command sequence handled by CCL 
to prepare a terminal to execute the privileged commands 
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but block users from entering this terminal. Next we do 
the normal REDs that RSX would normally do on wakeup. 
Since CO: is redefined to NL:, the normal messages and 
REDs disappeared. We also fake the normal print out of 
these messages by copying a canned message from a file 
that looks like the normal message. Next in the se¬ 
quence is the login dialog. We first open a file in 
another privileged user account by .OPEN command and as 
a result of the dialog sequence build the sequence of 
privileged commands that must be executed. The entire 
sequence on the consol is unprivileged. We now use FRC 
(see DECUS tapes) to log on a receive-only terminal or 
some terminal that will execute the privileged commands 
but can not be intercepted by the user and aborted. 
Some techniques for such a terminal are: a receive-only 
terminal (with no keyboard), setting a terminal to a 
speed lower than 300 baud if the Jumper on the DZ's dis¬ 
tribution panel for that port is cut, or setting the 
speed DZ's port speed to 7200 since VTlOOs do not have a 
7200 rate. Next we force a HEL message to the terminal 
to login a privileged account. This automaically starts 
Its L0GIN.CMD filewhich then starts the command file 
that was previously built, deltes it, restores its ter¬ 
minal attributes to what they are supposed to be and 
exits. It is a wonderful experience to see a receive 
only terminal login to a system and start working on its 
own initiative. Also hide as much of the commands as 
possible to the users eyes by either using .ENABLE QUIET 
and/or putting them in SYSCCL. One may continue ad in¬ 
finitum complicating the processby different versions of 
CCL and SYSCCL.CCL, FRCing commands all over the 
system,and chaining of either tasks (spawn is helpful 
here) or indirect command files. By the way the .ENABLE 
QUIET did not work on my RSX 3.2 system but did on 4.0. 
Also there are tasks around that simply turn off or on 
the privilege bit for the user. I strongly recommend 
NOT having such a task installed in the system. 

One way of hiding ACNT is renaming it to something 
like BASLIB.OLB and putting it with the libraries in 
[1,1] on the system disk. (We don't use BASIC) Pick a 
name consistant with a possible language but one not in 
use. This way the file can be inconspicuous in that it 
is contiguous but not an obvious candidate for a task 
image search command. 

Although this doues not eliminate all threats to 
system stability if does offer fundamental protection 
against some of the most dangerous aspects of the system 
in its most vulnerable state. 
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An RSX-llM Device Driver Implementing 
Network Protocols on the DR-llW 


D. Burch 
V. White 

Computing Department 
Fermi National Accelerator Laboratory 
Batavia, 11. 60510 


ABSTRACT 


At Fermilab, DR-llWs have been used as high speed 
data links to interconnect PDP-lls under both RT-ll and 
RSXll-M. An imo Iementati 0 n for VAX-lls (under VMS) is 
planned. Using this hardware, several processors can be 
used to provide distributed data collection, data moni¬ 
toring and control, in real-time, for physics experi¬ 
ments. 

This paper discusses a device driver which we have 
implemented under RSX-llM V3.2. This driver allows 
task-to-task logical connections to be estabi ished 
between a pair of connected PDP-lls. This driver imple¬ 
ments several unique software mechanisms including 
non-standard ASTs, driver maintained queues, and task 
rundown support. It allows a network operation to be 
processed with less than 6 ms software overhead. 

The reasons for choosing this method of implementa¬ 
tion are discussed, and problems solved are described. 

Plans for the future development of utility 
software will be briefly mentioned. 


Introduction 

The Fermi National Accelerator Laboratory (Fermi¬ 
lab) is a national laboratory dedicated to pure research 
in the field of high energy physics. Research Is per¬ 
formed by a large number of experimental groups each 
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using a dedicated minicomputer for data acquisition. 
Experiments at Fermilab are based on the use of a proton 
accelerator (proton synchrotron) which provides an in¬ 
tense beam of protons for one second out of every ten 
second accelerator cycle. During this one second period 
(known as the accelerator "spill"), the minicomputer for 
each experiment acquires as much data as possible from 
the experimental apparatus. The data is accumulated in 
the form of "events", each containing the information 
recorded by the experimental apparatus for a single in¬ 
teraction between the elementary particle beam and the 
atoms in a target. Depending on the experiment, the 
size of an event can vary from one word of data to sev¬ 
eral thousand words of data. In many experiments, the 
amount of data which can be accumulated during each 
spill is limited by the rate at which the computer can 
transfer the data from the experimental apparatus. Data 
acquisition rates can run as high as 300,000 words of 
data per spill, with typical rates being about one quar¬ 
ter of this. 

In addition to accumulating data and storing them, 
normally on magnetic tape, the online computers must 
monitor the accumulated data and carry out direct checks 
of the hardware to verify the proper functioning of the 
entire experimental apparatus. 

Fermilab is currently embarked upon a program of 
improvement in order to meet the future needs of high 
energy physics. This program involves the construction 
of a new proton synchrotron that will provide protons 
with energies of 1 TEV (One Trillion Electron Volts). 
The principal effects of this program upon the data ac¬ 
quisition environment are the increase of the spill time 
to twenty seconds out of every sixty, and a marked in¬ 
crease in the complexity of the apparatus of some exper- 
imen ts . 

In order to meet the data taking needs of this new 
era in high energy physics, it became apparent that cur¬ 
rent data acquisition systems were not adequate. After 
consideration of many alternatives, it was decided to 
implement a distributed processing system in which 
PDP-lls and VAX-lls are connected by a high speed 
DMA-type communications device. Me chose the DR-llM. 

The DR-llM is a device capable of transmitting data 
buffers from one UNIBUS to another in DMA mode. It does 
so (In non-burst mode) at a rate of three microseconds 
per word. The peak (burst mode) rate is about two mi¬ 
croseconds per word (8,000,000 baud). It is capable of 
operating only over short (fifty foot) distances, but 
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this was not a limitation in our environment. The 
DR-llM is low in cost, readily available, DEC supported, 
and available from a second source. 


Link Protocol 

In this section we will consider the protocol steps 
involved in a normal transfer operation of a single 
block of data (referred to as a "packet") between one 
and 32,000 words in length. Exceptional cases such as 
errors, restarts, collisions, and timeouts will not be 
discussed here. Me will note, briefly, the possible ex¬ 
ceptions to this protocol which cannot be considered er¬ 
rors. 

Our link protocol supports both the transmission of 
blocks of data and single byte values known as Signals. 
A signal is transmitted with a shorter protocol ex¬ 
change, and therefore is suitable for the rapid transfer 
of simple control data. Data blocks are moved in DMA 
mode, and protocol exchanges occur in programmed data 
transfer mode. 

The DR-llM is a half-duplex device, and therefore a 
bid for ownership of the link must occur before a 
transfer operation can take place. A link operation 
starts with one side of the link (the Sender) issuing a 
Request Link. It's partner (the Receiver) responds with 
a Link Acknowledge. 

Next, the Sender transmits a Packet Type Code (PTC) 
to the Receiver. The Receiver responds to the PTC ei¬ 
ther with a PTC acknowledge or a PTC NACK. The PTC NACK 
exists to allow a Receiver to reject certain types of 
link transactions. 

Next, the Sender transmits either a Word Count for 
the transfer to be performed, or a Signal. A signal can 
be identified because the sign bit is set and a the 
upper byte is filled with a particular pattern. The Re¬ 
ceiver responds either with a Signal Acknowledge, with A 
Permitted Word Count, or with a Word Count NACK. The 
Permitted Word Count is the amount that the receiver ac¬ 
tually wishes to receive. By means of this feature, a 
transmitter can send pieces of a large buffer to a re¬ 
ceiver which does not have a buffer large enough to con¬ 
tain the complete message. 1 he Word Count NACK allows a 
Receiver to reject a transmission which is for some rea¬ 
son not of the correct length. If the receiver sends a 
permitted word count, it first sets up it's DR-llW for 
the DMA operation. 
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Following the receipt of the Permitted Word Count, 
the Sender sets up its DR-llW device for a DMA, and be¬ 
gins the DMA operation. 

After completion of the operation, the Receiver de¬ 
termines whether it has received all of the expected 
words, and also whether it has any messages waiting for 
the link, and from these determinations forms an End of 
Message Status Code. The Receiver then transmits the 
End Of Message Status Code to the Sender. 1 he capabi I i- 
ty of a Receiver to request the link at the end of a 
link operation is important in cases where a Sender is 
much faster than a Receiver, and could turn around and 
win the link bid process after each transmission. It 
also reduces the number of protocol steps during times 
when the link is seldom idle. The End of Message Status 
Code completes the link operation. See Figure One for a 
diagram of this process. 


Program-to-Pr 0 gram Protocol 

Implied by the Link Protocol is the 
Program-to-Program or Network Protocol. This system 
does not address the concept of "route-through". It 
only provides for communication between a pair of con¬ 
nected machines. To allow all members of a network 
using this system to communicate with one another with¬ 
out providing application specific routing software, one 
would have to connect each machine to every other ma¬ 
chine in the net. 

The Packet Type Code (PTC) identifies a logical 
link from some procedure to a Receiver. In a 
multi-tasking system, such as RSX or VMS, this value is 
associated to a particular task. A "Packet Type Affini¬ 
ty” is then said to exist. By this method, a data block 
can be sent from a buffer within a task running one ma¬ 
chine directly to a buffer in a task running in the re¬ 
ceiver machine. 

In order to make the operation of a system using 
the link as insensitive as possible to the type of oper¬ 
ating system running in a connected machine, we chose 
numbers rather than task names to identify logical 
links. The PTC destination address mechanism provides a 
logical link in one direction only, that is, from a 
sender to a receiver. The receiver has no information 
about the sender of a message other than which LUN the 
message was received from, and therefore, which physical 
machine the sender resides in. 
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For this reason, application code protocols must 
exist if the receiver of a message must know anything 
about the message's sender. 

Depending on the implementation of this protocol, 
it is possible for a task using the link to be informed 
of the nature of a packet before it specifies a buffer 
for the receipt of the packet. The task then has the 
option of specifying a sufficiently large buffer, some 
smaller buffer if wants less than the entire buffer, or 
rejecting the transaction entirely, which causes the 
I ink serving mechanism to issue a Word Count NACK. 

The signal mechanism is intended to provide a low 
overhead mechanism to transfer control information. In 
the case of RSX-11, the Receiver does not need to issue 
an I/O operation to receive a signal. In place of an 
I/O operation, an AST is forced to the task with the 
signal on the AST stack. 

Each Task willing to receive a message must declare 
which PTCs it intends to receive. Note that one and 
only one task may establish affinity for a particular 
PTC at a given time, but as soon as that affinity is re¬ 
moved (either explicitly or through the demise of the 
task), any other task may obtain an affinity for that 
PTC. 

Note that ail data blocks are moved in DMA mode di¬ 
rectly from one task's buffer into another task’s 
buffer. No intermediate pools or buffers are involved. 


The RSX-llM Device Driver Implementation 

The RSX-llM Implementation of the above protocols 
is in the form of a device driver. Tasks using the Com¬ 
munications Driver <CD:>, communicate with It via the 
QIO directive. Currently, this driver has been imple¬ 
mented as either a loadable or resident driver for 
18-bit mapped PDP-lls. It is capable of handling com¬ 
munications to any number of DR-llW connected proces¬ 
sors, as well as task-to-task communication between 
tasks running in the machine In which the driver re¬ 
sides. 

This latter feature is interesting because it al¬ 
lows all programs in a system to communicate with each 
other via a standard interface. This allows functions 
in the distributed processing system to be Independent 
of their position within the system, and allows debug¬ 
ging of software on a single machine. The internal com¬ 
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munications option can be generated into a driver which 
does not support any physical DR-llW units. It can, 
therefore, run on a 22-bit mapped PDP-11. 

In order to create a Packet Type Affinity, a spe¬ 
cial I/O function is executed which specifies the PTC 
that the task needs to receive, and an AST address which 
will be used upon receipt of a signal or when a message 
arrives with no read queued for that PTC. As described 
above, this allows a task to accept link transactions 
without always having an outstanding I/O packet. This 
allows the task to be checkpointable. Two I/O functions 
are provided to remove the Packet Type Affinities for a 
task. One removes a specific Packet Type Affinity, 
while the other removes all Packet Type Affinities for 
the issuing task . 

I/O functions have been implemented to read pack¬ 
ets, write packets, and send signals. The write func¬ 
tion specifies a packet address, packet length, and des¬ 
tination PTC as I/O parameters. The unmodified form of 
the read function is intended to receive a currently 
pending packet (one for which the task has received an 
AST). Since there can be one and only one pending pack¬ 
et for each DR-llW unit, the read function specifies 
only the buffer address and length. Note that untiI the 
Receiver issues it's QIO and the transaction completes, 
no other I/O may occur on that physical unit. Therefore 
any long series of transactions in this mode will decre¬ 
ase link throughput. An I/O subfunction has been de¬ 
fined that will allow a read operation to be queued to a 
particular PTC. This read operation will remain queued 
until a transaction is received for the PTC to which it 
is assigned. This is the recommended mode when large 
amounts of data are to be transferred. 

When a task receives an AST informing it that a 
packet is pending for a PTC for which it has declared 
affinity, but it is unable to process that packet for 
some reason, it can issue a special I/O function which 
causes a Word Count NACK to be issued, thereby rejecting 
that transaction and freeing the I ink. 

At Fermilab, we saw the need for some tasks to per¬ 
iodically gain exclusive use of the DR-llW link, prefer¬ 
ably without device driver intervention to avoid the 
system overhead time of performing a QIO. For this pur¬ 
pose, a subfunction bit has been defined for both the 
read and write QIO functions that will direct the device 
driver to "sleep", that is, to give up it’s ownership of 
the DR-llW interrupt vector. The intended use of this 
function requires that a pair of cooperating tasks exist 
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on either side of the link which is to be put to sleep. 
One of these tasks initiates the transaction by issuing 
a write-and-sIeep operation to a pre-defined PIC. The 
other task responds to the receipt of a packet AST for 
that PTC by issuing a read-and-sIeep operation. Upon 
completion of this transaction, the CD: driver in each 
machine removes it's interrupt vector and replaces it 
with the address of the nonsense interrupt handler. 
This fully interlocks the sleeping process. 

When the cooperating tasks have finished their use 
of the link, they each disconnect from the DR-llW inter¬ 
rupt and issue a special I/O function which restores the 
driver's interrupt vector and starts the link startup 
protocol. 

While the DR-llW interrupt is removed, link tran¬ 
saction I/O operations are rejected unless they contain 
a special subfunction bit which tells the driver to 
allow them to be queued until the interrupt is regained. 


7.0 INTERESTING DETAILS OF IMPLEMENTATION 


One of the more interesting details of the RSX-11 
implementation of this protocol is that it does not de¬ 
pend on the Ancillary Control Processor <ACP) mechanism. 
Originally, we had intended that the device driver be a 
much more modest entity, and that an ACP would handle 
the individual steps of the protocol and maintenance of 
the PTC tables. When we investigated this path, we 
found that the overhead time introduced by the ACP sche¬ 
duling mechanism was longer than our target for total 
overhead time. 

In order to perform the complex protocol and house¬ 
keeping chores, the device driver itself had to be con¬ 
siderably more complex than most RSX-llM drivers are (or 
should be ) . 

The CD: driver handles all of it's own queuing of 
I/O request packets. Write type I/O operations are 
queued to the standard I/O queue when needed (when the 
driver is busy upon receipt of the packet). Read opera¬ 
tions are handled quite differently. 

When a task creates a Packet Type Affinity, a Pack¬ 
et Descriptor Block (PDB> is allocated in the system 
pool. This PDB contains the 1CB of the owning task, the 
PTC it refers to, and the AST address specified by the 
task. The PDB is then linked to the end of a singly 
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linked list whose head is contained in a Unit Control 
Block (UCB) extention. Contained within the PDB, and 
initialized at creation time, is an I/O queue header. 
When a read operation is received for a particular PTC, 
that is, with the queue subfunction bit set and the 
third I/O parameter referring to a PIC for which the is¬ 
suing task has declared affinity, the I/O packet is 
queued to this PDB I/O queue. For a picture of these 
pool structures, see figure two. 

One particularly nasty feature of the DR-llW when 
used as an interprocessor communications device is that 
interrupts from a connected machine may be lost if the 
Interrupt Enable (IE) bit in the device's CSR is turned 
off. This feature dictates some of the more interesting 
elements of the CD: design. 

The CD: driver maintains two independent execution 
streams. One stream handles the I/O functions that 
transfer data. It is driven by the completion of I/O 
operations if the device is busy, and started by either 
the receipt of a QIO packet or by an unsolicited link 
transaction. Transfer functions are terminated through 
the $I0D0N executive subroutine. The second execution 
stream handles so-called control or housekeeping func¬ 
tions. These functions are never queued, and are exe¬ 
cuted immediately upon receipt of the QIO packet which 
specifies them. Control functions are terminated 
through the use of the $I0FIN executive subroutine. 

Because an interrupt from the DR-llW may occur at 
any time during the protocol and in any driver state, 
the management of interrupt and fork-level code is com¬ 
plex. Interrupts can arrive faster than we expect them 
to, or some error may have occurred in the machine the 
driver is communicating with, causing a link startup 
code, or simply garbage, to be received. To handle 
these situations, the driver follows certain rules such 
that it's current state is always known while it is exe¬ 
cuting at below the priority of the device interrupt. 
At the interrupt entrypoint, a dispatch/action state 
table is consulted. If any currently executing 
fork-level code needs to be informed of the result of 
the interrupt, state flags are set which the fork-level 
code is required to consult before it terminates it's 
operations. This function is simplified through the use 
of central routines which effect the entry to and exit 
from a particular state. 

As was previously mentioned, the CD: informs a 
task of the receipt of a signal or an unsolicited tran¬ 
saction through the use of an AST. This non-standard 
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AST block is allocated from pool, and queued to the task 
using the $QASTT executive subroutine. The AST stack 
contains the PTC which generated the AST, the unit 
number of the interrupting unit, and either the word 
count for the data packet or the signal. Including the 
unit number and the PTC allows one AST routine to suf¬ 
fice for a task which connects to several units and/or 
has multiple Packet Type Affinities. 

Because the CD: driver maintains non-standard I/O 
queues, it must intercept and process I/O Kill func¬ 
tions. Any write QIO packets that are on the system I/O 
queue for the unit are removed by the executive, and 
then the driver is called to complete the operation by 
scanning the PDB I/O queues. 

Mhen a task exits, it is important that any pool 
structures which it has created are removed. To allow 
the CD: driver to perform this function, an RSX-llM I/O 
function known as lO.CLN is used. In an RSX-llM system, 
lO.CLN is issued by the I/O rundown service when a task 
exits with a file open. The intention is that the 
FILES-11 ACP will intercept the function and close the 
file. The CD: driver marks the second word of the LUN 
entry in the header of any task which creates a Packet 
Type Affinity. This fools the I/O rundown service into 
believing that a file is open on that LUN, and it sends 
the driver an lO.CLN I/O request packet. The driver 
responds to this packet by removing all PDBs owned by 
that task. 

An interesting build-time option of this driver is 
the trace feature. If the trace feature is present, the 
driver looks through the Partition Control Block (PCB> 
chain for a partition called CDTRAC. If this partition 
is available, some words at the beginning of it are ini¬ 
tialized, and the partition is marked as busy so that 
nobody tries to load anything over It. At key points in 
the driver's code, a TRACE macro is invoked. This macro 
creates a call to a tracing subroutine and passes a par¬ 
ameter Iist to it. The trace subroutine checks a flag 
in the UCB to see if the trace partition was initial¬ 
ized, and if so it checks a bit in the partition to see 
if tracing was enabled (the trace enable bit is set by 
an external task). If tracing was enabled, it moves the 
current clock tics into the next free position in the 
trace partition (defined by pointers at the beginning of 
the partition) followed by the parameter list. A dump 
program has been written which decodes the data in the 
trace partition and displays them on a terminal or a 
lineprinter, and which can enable or disable the trace 
feature. This allows rapid fault isolation. This code 
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and the dumping task are sufficiently modular that the 
writer of any new driver should consider using them. 


Timing and Size of Code 

The CD: driver may be generated with any combina¬ 
tion of several options. It may contain (or not) physi¬ 
cal DR-llW support, intraprocessor (internal to a single 
machine) communication support, and the trace feature. 


Me assembled the driver using the combinations of these 
options to determine code size. The results were: 

1. Physical, Trace, and Intraprocessor - 2853. 
words. 

2. Physical, no Trace, and Intraprocessor - 2011. 

words. 

3. Physical, Trace, no Intraprocessor - 2601. 
words. 

4. Physical, no Trace, no Intraprocessor - 1805. 

words. 

5. No Physical, Trace, and Intraprocessor - 1383. 

words. 


6. No Physical, no Trace, and Intraprocessor 
899. words. 


The size of the pool structures needs to be consi¬ 
dered when planning a sysgen for a system which will use 
this driver. The following numbers are for a loadable 
driver for a non-muItI-user system. The Device Control 
Block (DCB) is fifteen words. The size of the Unit Con¬ 
trol Block (UCB) is thirty-three words, and must be re¬ 
peated for each unit. The size of the Status Control 
Block (SCB) is twelve words and must be repeated for 
each unit. Each Packet Descriptor Block (PDB) takes up 
seven words. 

The following average timings were made for commun¬ 
ications between an 11/34 and an 11/50; 

1. One word packets - 5.7 ms/lransfer. 

2. Ten word packets - 5.8 ms/7ransfer. 

3. 500 word packets - 7.3 ms/Transfer 


104 



4. 


1000 word packets 


8.8 ms/lransfer. 


5. 2000 word packets - 11.9 ms/lransfer. 

6. 4000 word packets - 17.9 ms/7ransfer. 

These timings compare favorably with those for 
other high speed devices. Me timed transfers to an 
STC-1900 tape drive at 6250 BPI, and found that a 4000 
word transfer took 24.3 ms on average. A 4000 word 
transfer to a TU-IO (800 BPI) took 247.5 ms on average, 
to no one's surprise. 

Me ran the i ntraprocessor version of the driver on 
a PDP-11/70, and recorded an overhead time of less than 
5 ms . 

Note that when the Trace feature is in use, the 
overhead per transfer goes up markedly. 

Miscellanious Asides 

There are a few things that ought to be noted in 
pass i n g. 

The RT-11 implementation of this protocol is compa¬ 
tible with the RSX-llM implementation, permitting appli¬ 
cations under the two operating systems to communicate. 

The intrapr 0 cess 0 r communications feature uses the 
$BLXI0 executive subroutine to transfer data from one 
task buffer to another. If this feature is to be used 
in your system, you should specify the maximum size for 
the $BLXI0 vector in your SYSGEN options generation ses¬ 
sion. 

The link startup protocol depends upon having a 
source of essentially random numbers to function depend¬ 
ably. Me used the location $IDLC1 which is a count of 
idle cycles updated by the rotating data light support 
routine. Unless you wish to modify the driver, we sug¬ 
gest that you include this option in your system genera¬ 
tion. Me routinely run our system on ll/34s and ll/60s 
which do not have data lights, and have experienced no 
problems with that to date. 

Me have created a subroutine package, called 
CDPACK, which provides an operating system independent, 
FORTRAN-ca I I ab I e interface to the communications ser¬ 
vices. Currently, versions of this package written for 
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RT-11 and RSX-llM are completed, and a VMS version wil' 
be produced as VMS support is added. 

Me are currently adapting our Data Aquisition and 
Analysis systems to use the DR-llM services. Our future 
projects will probably include remote access to CAMAC 
device drivers through the use of ACPs and remote 
servers. File Transfer, and some sort of virtual termi¬ 
nal support. 

The current version of the CD: driver, the trace 
dumping task, and CDPACK will be on the RSX-11 Special 
Interest Group tape for this DECUS symposium. 


Conclusion 

The DR-llM-based communications architecture devel¬ 
oped at Fermilab is suitable for situations in which 
rapid data transfer is more important than such features 
as error detection and retry, although such features 
could be added with an application layer. This archi¬ 
tecture is currently being used to develop applications 
to support the high energy physics community at Fermi¬ 
lab, and its widespread use at Fermilab is forseen. 
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RSX-llM V4.0 System Generation 

Ralph W. Stammerjohn 
Monsanto 

800 N. Lindbergh 
St. Louis, Missouri 63167 

Me have recently completed generating RSX-llM V4.0B 
for the nine Monsanto PDP-11 systems. We set out with 
three major goals: 

1. Minimize the differences between systems as 
much as possible. We wanted to keep the actual 
number of copies of various task images, espe¬ 
cially privilege tasks, to a minimum. 

2. Make the system as friendly to use from the 
terminal as possible. 

3. Maximize the amount of available executive 
pool. Me have historically tried to do more on 
a RSX-llM system then we should and pool has 
always been the limiting factor. 


In general, we have met alI of these goals. This 
report covers the key actions we took, concentrating on 
changes to RSX-llM that helped us reach our goals. We 
also discuss various problems we encountered and our 
system generation methodology. Specific patch files can 
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be found at the end of the article. 


8.0 MINIMIZING SYSTEM DIFFERENCES 


The nine separate systems include PDP-ll/23‘s, 
11/34’s, 11/44‘s and 11/70‘s. All systems have differ¬ 

ent device configurations and even when they support the 
same device, the hardware addresses are different. All 
systems have memory management and floating point units. 

We first listed the executive features we required 
for each system. We then did a dummy system generation 
and selected the union of all features. The actual 
differences were minor because we have consistently used 
the same approaches in each application. We included 
the new executive commons, pool monitoring and alternate 
CLI support. Specific features not selected included 
powerfail recovery, set system time, group global event 
flags, c 0 nnect-to-interrupt, disk writecheck, and XDT. 
The first two are not needed because we have UPS and 
time — of — day clocks on all systems and the last four fea¬ 
tures are not used or cost significant pool space. 

Me also selected the union of all devices between 
our systems during the dummy generation to see what con¬ 
figuration symbols would be generated. 

When we examined the resulting configuration file 
<RSXMC.MAC>, it was clear the only differences were ex¬ 
tended memory support (22-bit addressing), the crash 
dump device, and actual peripherals. 

A RSX-llM privilege task uses the symbol defini¬ 
tions in RSXllM.STB to map references in the executive. 
If all global references used by a privilege task are 
identical between two executives, the same copy of the 
privilege task can be used on both systems. 

Me decided to restructure the executive so only two 
different versions of privilege tasks would be needed, 
one for 18-bit systems (11/23, 11/34) and one for 22-bit 

systems (11/44, 11/70). We would build unique execu¬ 

tives for each system. The following changes were made: 

1. The crash dump module (CRASH.MAC) conditionally 
assembles unique code for the specific crash 
device. Our first thought was to make the 
length of each code segment the same, thereby 
making the position of modules following the 
crash module the same in all systems. This ap- 


108 












proach was discarded because it would be diffi¬ 
cult to maintain and waste space on some sys¬ 
tems. 

The approach used was to split the crash module 
into two files, CRSHP and CRSHC. The first 
file has the crash dump stack and the crash 
dump entry points. The module would be the 
same size no matter what crash device is se¬ 
lected. The second module has the actual crash 
dump code and contains no global references 
used by privilege tasks. Me placed this module 
at the end of EXC0M2. A side benefit was an 
increase in pool because the crash code no 
longer subtracted from the 20KW kernel execu¬ 
tive. 

2. All other code in our two executives was the 

same until we reached the device tables 

(SYSTB.MAC). Me looked at the dummy SYSTB.MAC 
file that had the union of all devices and 
checked to see what global references were made 
by privileged tasks. These turned out to be 
the console terminal <TT0:), console device 
(COO:), and several psuedo devices. In addi¬ 
tion there are some special structures used by 
the terminal driver. 

Me needed to make the references have the same 
addresses on all systems. Me did this by edit- 
ting a new module (OEVIB.MAC) from the device 
database code that had ITO:, COO:, NLO: and 
the various psuedo devices. Then unique data¬ 
bases for the remaining systems were created as 
separate files. 

3. The only module which follows the device data¬ 
bases is the system initialization code 
(INITL.MAC). This module does the basic system 
startup when a virgin image is booted and then 
links itself into pool. The only global label 
in this module is at the start of the module 
($P00L>. This is used in various privilege 
tasks to find the start of pool. 

Me added a new word to the executive common 
data base (SYSCM.MAC) named $POOLA and modified 
INITL.MAC to store its starting address in this 
word. Then all references in privilege tasks 
to $P00L were changed to use the contents of 
$P00LA. 
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These three steps allowed us to build two dummy ex¬ 
ecutives, one for 18-bit systems and one for 22-bit sys¬ 
tems, and use the resulting RSXllM.SIB files to link two 
sets of privi lege tasks that would work on al I systems. 
Me setup RSXMC.18B and RSXMC.22B as the configuration 
files for both systems and created two separate object 
libraries. In separate accounts for each actual system 
we put a RSXMC file that had the specific system name, 
CPU, and crash device, the system unique device configu¬ 
ration source, and the executive build files. The only 
unique objects needed for each system were CRSHC (the 
unique crash device), SYSTB (unique devices), and SYSCM 
(unique system names). 

All of our device drivers are loadable. Device 
drivers have internal storage based on the number of 
devices and controllers, but this is typically only one 
or two words per device. The RSXMC.18B and RSXMC.22B 
configurations had the union of all devices so we assem¬ 
bled the drivers using these files and generated Just 
two sets of loadable drivers. 

The same approach was used with DECnet support. 
For configuration reasons, Monsanto uses DECnet-llM 
V2.0. Me generated two versions of DECnet that had the 
union of dll network devices used in the system. Each 
system then as a unique configuration file (CETAB.MAC) 
that loads only the actual device and sets its vector 
and CSR address and other unique network parameters. Me 
actually generated four versions of device drivers and 
DDCMP in order to support whether the system had a KGll 
or not. 

In summary, we were able to support nine different 
RSX-llM systems with Just two sets of privilege tasks 
and loadable device drivers. The executive and driver 
source modules are assembled only two times, once for 
18-bit support and once for 22-bit systems. Unique 
CRSHC, SYSCM, and SYSTB object files are made for each 
system and specific RSXllM, EXCOMl , and EXC0M2 images 
built. All privilege tasks and device drivers are 
linked to the dummy symbol table file for 18-bit and 
22-bit s y s terns. 


9.0 SYSTEM FRIENDLINESS 


System friendliness at Monsanto means letting each 
programmer use whatever command language they desire and 
as much shorthand as possible. At the same time, we 
also have a goal of minimizing pool usage and this means 
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keeping tasks not installed unless they are actually 
being used. 

The KMS Fusion CCL program and INSTALL /CMD are 
perfect for this purpose. CCL operates as a catch-all 
task and any commands which MCR cannot directly process 
are forwarded to CCL. So if a user types MAC A=B and 
...MAC is not installed, CCL will get the command line. 
CCL can then issue an INS $MAC/CMD="MAC A=B" and the as¬ 
sembler will be installed on the fly, do the assembly, 
and be removed. 

The normal command we use at Monsanto to run a task 
that is not installed is 

INS f i I ename/TASK = namtxx/CMD=''nam command" 

where filename is the task image filename, nam is the 
first three characters of the command verb, txx is the 
terminal number, and command is the actual command 
string. For example, our CCL TYPE command would gener 
ate the fol lowing MCR command when issued from TT11 : 

INS $PIP/TASK = TYPTU/CMD = "1 YP TI: = file(s>" 

This is the same form of command that would be generated 
by OCL. We chose this command format because we did not 
want programmers to get confused about what task to 
abort when changing between DCL and MCR. 

However, there is one major problem. RSX-llM lim¬ 
its ail MCR command lines to 80 characters. This means 
the actual command line that can be used with the /CMD 
switch is 80 minus the overhead of the INS command. The 
overhead for our shortest form would be the above exam¬ 
ple or 28 characters. It could be more if we would use 
an actual f i Iespecif i cation and becomes a problem for 
commands that normaly have long command Iines (MAC, PAT, 
etc.) 

We decided to recode CCL to resolve this and other 
problems. The new program, CCS, would support the CCL 
notation with some new extensions but would use TPARS 
for all parsing, use the new Request and Pass Offspring 
Information (RPOI) directive, have extended command 
search algorithms, eliminate parts of CCL we did not use 
at Monsanto, and solve the problem of the 80 character 
command line. 

1. We used TPARS because it would make it easier 
to add extensions to CCS command processing in 
the future and give us better parsing control. 


We implement TPARS state tables that handled 
al I of the current CCL syntax and added a %N 
option. This is the reverse of %Q or execute 
the command line if the tested parameter is 
null. 

2. The new RPOI directive solved a problem with 
CCL that existed in V3.2. When a catch-all 
task is invoked, MCR passes any offspring in¬ 
formation <OCB) it has to the catch-all task. 
But in V3.2 there was no way for the catch-all 
task to pass the OCB's onto its spawned task 
(except through executive modifications done by 
Dan Steinberg to the spawn directive). 

The problem this caused is best illustrated by 
CCL commands issued from an indirect command 
file. If CCL exited after spawning MCR with 
the command line, indirect would continue pro¬ 
cessing because it thought the command was fin¬ 
ished. Also, no exit status would be returned. 
CCL had to wait until the spawned task would 
finish and pass the exit status it received 
along to its parent. CCL ‘ s waiting around used 
unnecessary resources and prevented other CCL 
commands from being issued when working inter¬ 
actively. 

The RPOI directive solves this problem and we 
coded CCS to use the directive whenever it con¬ 
structed the last command in a sequence. 

3. CCL would search various places for matches to 
the command: an internal file, a user file and 
the system file. We wanted to extend the al¬ 
gorithm to be table driven and add searching by 
task filename. Our implementation first checks 
the internal file. Then the command verb is 
used as the name of a task file and a search is 
made for the file using a table of dataset des¬ 
criptors. If the file is found, the command 
line shown above would be issued with the fi¬ 
lename as the command verb. Finally, CCS 
searches for CCL command files, again described 
by a table of dataset descriptors, and then 
searches these files the same way the internal 
file is searched. 

4. CCL had a lot of configuration options we did 
not use at Monsanto, so while writing CCS, we 
cleaned up the code and eliminated those fea¬ 
tures we did not use. 


Ill 
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5. 


The final change is the most critical. Mhen 
CCS finally constructs a command, it checks the 
resulting length. If less than 80 characters, 
CCS uses either the SPUN or RPOI directive to 
issue the command and either waits or exits. 

But if the command is longer than 80 characters 
and is in the typical format: 

INS fi I ename/TASK = namtnn/sw.. ./CMD = "command" 

we removed the /CMD part of the command line 
and check to see if the actual command line is 
no longer than 80 characters. If this is true, 
the following logic was used: 

1. Raise CCS’s priority to 255. 

2. Send the command line, without the /CMD 
part, to MCR to install the task. Wait for 
INS to finish and take immediate control 
(because we are the highest priority task 
in the system). 

3. Now issue either the SPWN or RPOI directive 
to the task directly and pass the actual 
command line. 

4. Enter system state and find the Task Con¬ 
trol Block for the target task. Set its 
remove-on-exit bit <13.REM) and propagate 
CCS's MCR prompt bit (73.MCR). Turn CCS’s 
prompt bit off and exit back to task state. 
This will cause the target task to be re¬ 
moved when it exits and cause a CLI prompt. 

5. Return back to CCS ' s installed priority. 

The logic works quite well, at the cost of mak¬ 
ing CCS into a privilege program. We are now 
able to run our systems with only two installed 
MCR tasks, INS and HEL. AlI other tasks are 
installed only when actually used and there is 
no command line penalty for the flying install. 

There were other actions taken in the area of sys¬ 
tem friendliness. First, INS has an option in the task 
build command file to allow non-pr i v i Iege users to in¬ 
stall n 0 n-priV i Iege tasks. This is the option statement 
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GBLPAT 


INSR0T:$PRVT:240:240 


and is normally commented out. We naturally enablec 
this so CCS would work for flying installs. In addition 
we added a similar global label, $PRVP, to allow 
non-privilege users to do privilege installs. This does 
not effect system security because privilege programs 
typically do further security checks and let us invoke 
programs such as MOU and DM0 using CCS. Those tasks 
that do present a security problem, like BOO, we simply 
hide in an account that non-privilege users cannot ac¬ 
cess. 

Next, the indirect command processor (ICP) had a 
task build option for a system library account to search 
if the command file was not found in the current user's 
account. This feature is enabled by setting the value 
of the option statement to the binary default account. 
We used LB:C1,2], done with the following statement in 
ICPBLD.CMD 

GBLDEF = D$CUIC:402 

In addition, we patched the search algorithm in ICP to 
first search SY:C1,2D before the check in the system ac¬ 
count. This let separate projects, all working from 
different virtual disks, to set up their own unique li¬ 
braries of command files. 

With RSX-llM V4.0, we decided to be more aggressive 
and use more software from the DECUS tapes. We examined 
all the tapes and compared different versions of various 
common items. We use the following under RSX-llM V4.0 
with no problems: 


TECO V36 

editor 

Sp r 

ing 1380 

[343,002] 


Text 

DOB 00 

dis a s s emb 1 e r 

Fal 

1 1980 

[301,052] 


Object 

REI VOl 

1e te d file 

Fal 

1 1980 

[307,022] 

Unde- 


GREP 010102 

tern search 

Fal 

1 1981 

[315,100] 

Pat- 


RUNOFF M2.4 
formatter 

Fal 

1 1981 

[305,302] 


Text 

SRD 

rectories 

plus 

(patches) 

6.1 

Fal 

Spring 

1 1981 

1981 [373,004] Di- 

[352,004] 


Finally, using the version 6.1 of SRD and the new 
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powers of the indirect command processor, we wrote OPS. 
This command file takes a SRD command line and prototype 
MCR commands and issues the NCR commands for each occu¬ 
rence of the files found by SRD. This essentially ex¬ 
tends the wild-card powers of SRD and PIP to all tasks. 
For example, the following OPS command does an assembly 
of all files created on November 11, 1982. 

@0PS <*.MAC/DA:ll-N0V-82> (MAC $F,$F/-SP/CR=$F> 

The prototype command use $x for various field substitu¬ 
tion and if no prototype command given on the first 
I ine, OPS wi I I prompt for any number of commands that 
will be issued in sequence for each file. 


10.0 MAXIMIZING POOL 


The limiting factor for the Monsanto systems has 
always been system pool. Maximizing system pool takes 
one of two forms: 

1. Maximize the total available system pool. 
RSX-llM‘s structure requires system pool to be 
in the first 20KW ' s of memory, so the maximum 
size of system pool is 120000(8) minus whatever 
code resides in this space. Any code removed 
from the first ZOKW's will increase available 
pool. 

2. Minimize the usage of pool. The key to minim¬ 
izing pool usage is never to tie pool up for 
inactive users, use as much secondary storage 
as possible, and keep the size of pool struc¬ 
tures to a minimum. 


The first steps we took to maximize total available 
space were obvious: select executive commons, use load¬ 
able drivers for all devices, and use the loadable task 
loader. The next step was to select only the executive 
features needed for our systems so unused features were 
not assembled. Me did choose the union of all features 
(see above), however, our most poo I-criticaI systems are 
also the ones that use the most features. 

The only other positive action we did in this area 
was to move the crash dump code to EXC0M2. This saved 
around 1400(8) bytes on our largest systems, as welI as 
made it possible to accomplish our first goal. He exam¬ 
ined moving other routines to the executive commons 


(PARTY, TDSCH, LRROR, PLSUB), but concluded the changes 
required would not be worth the gain in available pool. 


He were more sucessful in minimizing the usage of 
pool. The Monsanto systems are configured with lots of 
main memory, ranging from 124KM‘s on our 18-bit systems 
to 1088KM's on the 11/70‘s. Mhenever possible, we tried 
to trade memory for pool: 

1. The full-duplex terminal driver (TTDRV) is in¬ 
stalled in a 8KH partition. The actual code in 
the driver is only about 5KM‘s and the addi¬ 
tional space is used for terminal driver pool. 


2. CCS helped extensively to reduce the number of 
installed tasks. He are able to run our sys¬ 
tems with only seventeen basic installed tasks 
and still have the full power's of RSX. He do 
install SAV and MOU in our VMR command files 
but these are removed on system startup. 

TKTN Task termination 

LDR... Task loader 

PMT ... Pool monitor 

MCR... Command dispatcher 

FllACP FI Ies-11 ACP 

NETACP DECnet ACP 

...INS Install task 

ERRLOG Error logger 

COT... Console terminal logger 

PMD... Post-mortem dumper 

...MCR MCR command line interpreter 

...DCL DCL command line interpreter 

...CA. Catch-alI task (CCS) 

...HEL Login/help task 
...AT. Indirect command processor 
PRT . .. Print spooler (serial version) 
CRF... Cross referencer 


3. FllACP has Internal buffer space that can be 
expanded in the task build command files. Hith 
memory to burn, we decided to expand the large 
FllACP (FCPLRG) to 12KH’s and make the internal 
ACP pool ($$AFR1) for File Control Blocks as 
large as possible. He looked at the normal map 
and calculated the expansion size for various 
FllACP program sections. Unfortunately, this 
version of FllACP would trap as soon as mount¬ 
ed. Further investigation showed an undocu¬ 
mented restriction that PSECT $$BUF3 must start 
before virtual address 160000(8). Me redid the 
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calculations and were able to still add more 
FCB storage to FllACP than allowed in the dis¬ 
tribution command file. 

The distributed version of FCPLRG has the size 
of $$AFR1 as 3000(8) or 34 FCB's. Me are able 
to increase this to 4400(8) or 52 FCB's before 
hitting the 160000(8) limit. Me still found 
FCB's being allocated from pool on some systems 
so we mount different disks with different 
ACP’s. 

4. FllACP has an option to used fixed-size window 

blocks for open files or attempt to create a 
window block that exactly maps the entire file 
(/MIN = FULL ) . The second option saves pool 

space when opening small files. If only one 

retrieval pointer is needed to map the file, 
then a window block of size 24(8) is allocated 
instead of the 70(8) when fixed-size windows of 
7 are used. Unfortunately, the pathological 
files that are highly fragmented can cause win¬ 
dows in excess of 1000(8) bytes to be allocated 
from pool. 

Me patched FllACP to use full mapping instead 
of fixed-size windows, but to use the volume 
default window size as the upper limit. Me 
feel this gives us the best of both worlds. 
Small, existing files only use as much pool as 
they need. Large, fragmented files do not soak 
up extremely large segments of pool. Our typi¬ 
cal systems have 60 to 70 open fi les at any 
point in time so the resulting savings is sig¬ 
nificant. 

5. Me found the pool monitor feature of RSX-llM 

V4.0 to work quite well. A feature we enabled 
after reading the task build command file was 
periodic stop task checkpointing 

(GBLPAT=PMT;CNTRL : 160). Every sixty seconds, 
PMT will force a checkpoint for all stopped, 
non-ACP tasks. Me now see the console logger 
normally checkpointed has well as many of our 
own application tasks. Also, the indirect com¬ 
mand processors will be checkpointed when they 
are waiting on a long executions. Any tasks 
which stop but we do not want checkpointed we 
simply install with checkpointing disabled. 


RSX-llM V4.0, with these additional steps, seems to 
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have sufficient pool for even our largest systems. Our 
typical workload is around 25-30 active tasks and free 
pool from 3500 to 4000 words. Me have seen peaks of 
45-50 active tasks. 


11.0 PROBLEMS AND FEATURES 


RSX-llM V4.0B has been fairly problem free. Me 
have only encountered two serious errors, one bad patch, 
and two 'features' in our conversion from RSX-llM V3.2E. 

The first error we encountered were pool link er¬ 
rors that were traced to terminals used DCL. Me banned 
the use of OCL until ISC resolved the problem to a logic 
error in MCR (MCRDIS). Software Dispatch article 
2.2.1.2 (September 1982) fixes the problem. Note, the 
problem statement is somewhat misleading. Continously 
striking the PF keys certainly will cause the problem, 
but any command sent by DCL to MCR and on to the 
catch-all could corrupt the system. 

The other serious bug caused system crashes when a 
post-mortem dump was made of various tasks. Me traced 
the error to PMD's handling of tasks which map to a 4KM 
region using APR7, for example a 4KM non-overlaid 
FCSRES. The error is in PMD's handling of a high virtu¬ 
al address of 177777(8). PMD would increment the value 
to zero and then subtract the low virtual address to get 
the length of the region. The resulting bad value then 
caused bad memory transfers. 

Experience and conversations with TSC found the Au¬ 
topatch B TSHOM.COR patch to DCL is incorrect. Our new 
version of this file seems to fix the problem and is 
shown with the other file listings. 

The first 'feature' we discovered in RSX-llM V4.0 
was slaved terminals no longer had typeahead enabled. 
All of our actual applications have their own command 
parsers and run from slave terminals (these were all 
written before the days of CL I's) . lypeahead from these 
terminals is required to support the block-mode editting 
done on the terminals. Me examined the terminal driver 
and removed the new feature. Happily we discovered 
Software Dispatch article 3.1.3.1 (October 1982) had the 
same patch. 

Another 'feature' we discovered concerns the buffer 
size of the console terminal (CO:). In RSX-llM V3.2, 
the CO: device buffer size was 255 characters. It ap- 
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pears in the new release that the CO: device takes the 
buffer size of the terminal used for console logging, 
typically 80 characters. This broke various parts of 
our application packages until we found the problem and 
solved by simply making the buffer size of the console 
terminal larger. 


12.0 SYSTEM GENERATION AND SUPPORT 

Monsanto only uses the Digital system generation 
procedure long enough to generate the template configu¬ 
ration files and system device tables. Once we have 
this information, we use our own command files to assm- 
ble modules and put into the correct system library. 

We take a similar approach to task building. We 
ran SYSGEN3 and generated task build command files for 
everything. We then edit the command files and overlay 
descriptors into a standard format and enable or disable 
various options. 

Among the changes we made to the task bui Id command 
files is to consistently output task images to device 
TG:, output maps to device LI:, and input all source 
files from device SY; (except RSXllM.STB and CEX.STB 
which come from TG:). This lets us easily maintain two 
virtual disks, one which contains ail tasks and maps for 
18-bit systems and another for 22-bit systems. We set 
the state of the checkpoint </CP/-CP> and floating point 
</FP/-FP) switch explicitly and flag all maps for full 
listings (/MA ) and cross reference </CR>. All tasks 
also have explicit TASK, PRI, UIC, PAR, UNITS, ASG, and 
STACK options. This lets us do pattern searches to see 
the various parameter settings for all tasks. 

The following is a list of various other actions we 

did: 

1. We are currently using both Fortran-IV-Plus 
V3.0 and Fortran-77 V4.1 in production and 
wanted to avoid problems we had in the past 
with default SYSLIB.OLB searching. If one form 
of OTS was in SYSLIB, it would be certain that 
someone using the other compiler would forget 
and use SYSLIB.OLB as the default. The OTS 
mismatch would then cause strange problems. 

We decided to put no Fortran OTS (or ANSI FCS 
support) in SYSLIB. Instead, separate 
F4PLIB.0LB and F77LIB.0LB OTS-only libraries 
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were created. We also support SYSF4P.0LB and 
SYSF77.0LB as default libraries. This forced 
programmers to explicitly name the OTS they 
used. 

2. We have many application programs that link to 
the RSX-llM V3.2 FCSRES resident library. In 
order to avoid rebuilding ail these programs, 
we name the RSX-llM V4.0 resident library DE- 
CRES and support both on all systems. We will 
eventually migrate all FCSRES support to DE- 
CRES. 

3. Our systems have memory to burn, so we tried to 
find all tasks which benefit from additional 
dynamic memory and task built them as 28KW 
tasks (plus DECRES). This increases system 
throughput and helps the tasks show up on a 
1088KW RMDEMO display. The tasks that fall 
into this category include CMP, CRF, DSC, FTB, 
F4P, F77, LBR, MAC, PIP, TEC, TKB, and VFY. 

4. We examined the priority of all tasks and 
changed to better meet our needs. The basic 
question we asked as if these two tasks both 
wanf to run at the same time, which one should. 
We ended up setting the following priority 
classes: 

1. Priority 80 

All MCR privilege tasks except INS (ACS, 
BOO, BRO, BYE, DM0, ELI, HEL, INI, LOA, 
MOU, PMD, SAV, UFD, and UNL) . 

2. Priority 70 

All CL I command processors and video edi¬ 
tors (DCL, CCS, EDT). 

3. Priority 60 

The indirect command processor, other edi¬ 
tors, and file utilities (AT., TEC, PIP, 
and SRD) . 

4. Priority 50 

All of the other tasks with the exception 
of those at 40. 

5. Priority 40 
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Background tasks (CRF) and backup/disk 
utilities (BAD, BRU, DSC, FMT>. The later 
are normally run at standalone times and 
when used in production really consume sys¬ 
tem resources. 

There is also a category of system tasks that 
we put in individual priorities, starting at 
245. These task are ranked by descreasing im¬ 
portance, separated by units of 5. This allows 
us to put our real-time application tasks at 
exactly the right order with regard to the rest 
of the system. The current ordering for these 
tasks is TKTN, LDR, PMT, COL (SPM data collec¬ 
tion), RMD, MCR, FllACP, NLTACP, INS, ERRLOG, 
COT, MTAACP, PMD, and SHF. 


13.0 PATCHES AND FILES 


The following has many of the files discussed in 
the previous sections. The source patch files are in 
SLP autolocator format and the object patches in PAT 
form. 


13.1 Crash Module 


The following SLP correction file splits CRASH.MAC 
into two files, CRSHP.MAC and CRSHC.MAC. 

CRSHP.MAC/AU:72./-BF=CRASH.MAC 

-/.TITLE CRASH/,. 

.TITLE CRSHP 
-/; MODIFIED BY:/ 

; R. STAMERJOHN 19-JUL-82 

• RWSOOl -- SPLIT CRASH INTO POOL AND CODE MO¬ 
DULES 

; R. STAMERJOHN 07-SEP-82 

• RWSOll -- MAKE SURE MEMORY MANAGEMENT IS ON 
BEFORE JMP 

% 

-/$CRUST::/,/$CRPBF::/,/;RWSOOl/ 
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$CRUST : :.WORD 0 ; USER PS IS STORED 

HERE 

.IF DF D$$PARM$$MGE 

$CRAR5::.WORD 0 ; SAVED KERNAL APR 5 

VALUE 

.ENDC 

; *** THE FOLLOWING MUST BE 

ADJACENT 

$CRPBF::.BLKW 4 ;STACK AREA FOR SU¬ 

BROUTINE CALLS 

-/$CRSBN::/,/$CRSCS::/,/;RWSOOl/ 

-/$CRALT::/,/$BTSTP::/,/;RWSOOl/ 

$CRALT: : 

. IFT 

.IF DF D$$PARM$$MGE 

MOV KISAR5,$CRAR5 

MOV $XC0M2,KISAR5 

-,,/;RWS011/ 

BIS 1,@ SRO 

IS ON 

-,,/;RWS001/ 

.ENDC 

JMP $CRSHC ;JUMP TO CRASH CODE 

.IFF 

HALT 

-.,/BR .-2/,/;RWS001/ 

-.,.+3,/;RWS001/ 

/ 

CRSHC.MAC/AU:72./-BF=CRASH.MAC 

-/.TITLE CRASH/,. 

.TITLE CRSHC 
-/; MODIFIED BY;/ 

; R. STAMERJOHN 19-JUL-82 

• RWSOOl -- SPLIT CRASH INTO POOL AND CODE MO¬ 

DULES 

% 


;SAVE OLD MAPPING 
;MAP INTO EXC0M2 

;MAKE SURE MEMORY MANAGEMENT 
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-/$CRUPC::/,/$CRUST::/,/;RWS001/ 

-/; **★ THE FOLLOWING/,/; ★** ABOVE/,/;RWSOO1/ 

.IF OF C$$CDA 
-/;+/,/$TRINT;:/,/;RWSOO1/ 

.,/;RWS001/ 

-/$CRASH::/,/$CRALT;;/,/;RWSOO1/ 

$CRSHC:; ; CRASH DUMP ROUTINE 

.IF OF C$$RSH 

-/ UBMPR/,.,/;RWS001/ 

.IF DF D$$PARM$$MGE 

MOV $CRAR5,24<SP> ;;;STORE SAVE KERNEL APR 5 

.ENDC 

MOV UBMPR,RO ;;;GET ADDRESS OF FIRST UMR 

/ 


13.2 $POOLA Support 


The following SLP correction files add the new glo¬ 
bal variable $POOLA to SYSCM, modify INITL to intialize 
this variable to start of pool, and change all uses of 
label $POOL to reference the contents of $POOLA. Note, 
ST20V and MCRDEF are MCR modules and RMDDEF, MDINIT, 
THFllF, and THPAGE are RMDEMO files. 

SYSCM. MAC/AU; 72./-BF=:SYSCM. MAC 

-/; MODIFIED BY;/ 

; R. STAMERJOHN 19-JUL-82 

; RWS002 — ADD $POOLA WORD, HOLDS TOP OF POOL. 

% 

-/iCMFIN;;/,.,/;RWS002/ 

$POOLA;;.WORD 0 ;T0P OF POOL (fPOOL) 

$CMFIN;; ;END OF SYSCM AREA FOR CDA 

/ 

INITL.MAC/AU;72./-BF=:INITL .MAC 
-/; MODIFIED BY;/ 

; R. STAMERJOHN 19-JUL-82 


RWS002 — STORE TOP OF POOL IN $POOLA 


% 

-/BIC $CRAVL-2/, ,/;RWS002/ 

MOV RO,$POOLA ;STORE TOP OF POOL 

/ 

MCRDEF.MAC/AU;72./-BF=MCRDEF.MAC 
-/; VERSION;/ 

i R. STAMERJOHN 19-JUL-82 

I RWS002 -- REFERENCE $POOLA INSTEAD OF $POOL 


% 

-/$POOL/,.,/;RWS002/ 

.GLOBL $POOLA 

/ 

ST20V.MAC/AU;72./-BF=ST20V.MAC 
-/; MODIFIED BY;/ 

; R. STAMERJOHN 19-JUL-82 

I RWS002 — STORE TOP OF POOL IN $POOLA 


X 

-/SUB $POOL/,.,/;RWS002/ 

SUB $P00LA,R3 ; CURRENT AS TO BOUNDARY 

VALUE 
/ 

RMDDEF.MAC/AU;72./-BF=RMDDEF.MAC 
-/; MODIFICATIONS;/ 

; R. STAMERJOHN 19-JUL-82 

I RWS002 — USE $POOLA TO GET START OF POOL 


% 

-/$POOL/,.,/;RWS002/ 

.GLOBL $POOLA 

/ 

MDINIT.MAC/AU;72./-BF=MDINIT.MAC 
-/; MODIFICATIONS;/ 
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R. 8TAMERJ0HN 19-JUL-82 

RWS002 -- USE $POOLA TO GET START OF POOL 


% 


-/MOV 

$POOL/,.,/;RWS002/ 




MOV 

$P00LA,R1 

GET 

START 

OF POOL 

ASR 

R1 

IN 

32W BLOCKS 

ASR 

R1 




ASR 

R1 




ASR 

R1 




ASR 

R1 




ASR 

R1 




BIC 

1777,R1 

CLEAR ANY 

GARBAGE 


/ 


THFlIL .MAC/AU:72./-BF = THF1IL.MAC 
-/; DATE:/ 

• R. STAMERJOHN 19-JUL-82 

• RWS002 -- USE $POOLA TO GET START OF POOL 
% 

-/CMP R2, $POOL/,.,/;RWS002/ 

CMP R2,$P00LA ;; BELOW POOL? 

/ 

THPAGE.MAC/AU:72./-BF=THPAGE.MAC 
-/; DATE:/ 

• R. STAMERJOHN 19-JUL-82 

; RWS002 -- USE $POOLA TO GET START OF POOL 

% 

-/CMP RO, $POOL-l/,.+1,/;RWS002/ 

CHKADR: CMP RO,$POOLA 

BLO 10$ 

/ 


13.3 INS Support for Non-Privilege Installs 


The following SLP correction file adds a new global 
label, $PRVP, to INSTALL. This allows the error check¬ 
ing for non-privilege users installing privilege tasks 
to be disabled in the task build command file. 
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INSLB.MAC/AU:72./-BF=INSLB.MAC 
-/; MODIFIED BY:/ 

; R. STAMERJOHN 19-AUG-82 

; RWS007 -- ADD GLOBAL LABEL TO PATCH OUT PRIVI¬ 

LEGE INSTALL 

; CHECK FOR NON-PRIVILEGE USER 

% 

-/4912$:/ 

-/INSL21/,.,/;RWS007/ 

$PRVP:: 

JMP INSL21 ; NO 

/ 


13.4 Indirect Command File Lookup 


The following SLP patch adds SY:C1,23 to Indirect 
MCR‘s search path for command files. This also requires 
the task build value of D$CUIC to be set to 402(8). 

ICPATS.MAC/AU:72./-BF=ICPATS.MAC 

-/; MODIFED BY:/ 


R. STAMERJOHN lO-AUG-82 

RWS006 -- SEARCH SY:C1.2]. THEN LB:C1.2D FOR 


COMMAND FILES 
% 

-/BEQ 16$/,.,/;RWS006/ 

BLE 16$ 

THEN LB:C1,23 


-/16$:/, 

, ,/;RWS006/ 

TST 

R4 

BEQ 

17$ 

MOV 

CMBPTR,RO 

MOV 

"@L,(RO>+ 

MOV 

"B: ,(R0> + 

MOV 

1,R4 

BR 

10$ 

17$: 

-/ ”@L/, 

,/ •'B:/,/;RWS006/ 

MOV 

••@S,<RO> + 

MOV 

"Y: , <R0) + 


BR IF NOT, TRY SY:C1,2], 


IS THIS SECOND PASS 
BR IF NO, TRY SY:C1,23 
SET PREVIOUS COMMAND 
SET FOR 8LB: 

FLAG NO MORE PASSES 
AND RETRY OPEN 


; SET FOR @SY: 


126 











-/MOV 8P,R4/,.,/;RW8006/ 

MOV -1,R4 ; SET SWITCH FOR THIRD PASS 

/ 


13.5 OPS.CMO 


The following is the command file we use for 
wild-card support for all utilities. 

.ENABLE SUBSTITUTION 

.ENABLE GLOBAL 

OPS - Select files and perform operation. 

.; @0PS <SRD selection) (command string) 

.PARSE COMMAN "()()“ DUMMY SRD DUMMY CMDl 

.; If no command string specified, loop and read 
s tring s. 

.IF CMDl <> .GOTO SORT 
.SETN CMD 0 

.CMOS: .INC CMD 

.ASKS XXX Command string 'CMD' 

.IF XXX = "" .GOTO SORT 
.SETS CMD'CMD' XXX 
.GOTO CMOS 

.; Make SRD selection to temporary file and open for 
read. 

.SORT: SRD SRD.TMP='SRD '/L I 

.OPENR SRD.TMP 

.; Read SRD file and select filenames. Parse so $N 
is entire 

.; filename, $D is device, $U is UIC <$G is group, $0 
is owner), 

.; $F is filename, $T is filetype, and iV is version. 

.LOOP; .READ LINE 

.IFT <EOF> .GOTO FINI 

!sETS TEST LINEC1:33 

.IF TEST <> " **" .GOTO FILE 

.PARSE LINE " C,3" DUMMY DUMMY $D $G $0 DUMMY 

.SETS $U "C"+$G+","+$0+"3" 

.GOTO LOOP 
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.FILE: .SETS TEST LINEL20:203 

.IF TEST <> .GOTO LOOP 

.PARSE LINE DUMMY DUMMY $F $V DUMMY 

.SETS $T ••.”f$T 

.SETS $V '•;” + $V 

.SETS $N $D+$U+$F+$T+$V 

.; Enter loop and execute commands for each file. 

.SETN CMD 0 

.CHKS; .INC CMD 

.IFNDF CMD'CMD' .GOTO LOOP 
.TEST CMD’CMD' 

.SETN SIZE <STRLEN> 

.SETN CHAR 0 

.SETS OUT "" 

.CONT: ' .INC CHAR 

.IF CHAR > SIZE .GOTO EXEC 

.SETS TEST CMD'CMD'['CHAR';'CHAR'3 
.IF TEST = .GOTO SUBS 

.SETS OUT OUT+TEST 
.GOTO CONT 

.SUBS: * .INC CHAR 

.SETS TEST 

CMD'CMD'C'CHAR’;'CHAR’3 

.SETS OUT OUT+$'TEST’ 

.GOTO CONT 

.EXEC: 'OUT' 

.GOTO CHKS 

.FINI: PIP SRD.7MP;*/DE/NM 


13.6 FI 1ACP Windows 


The following PAT file allows FllACP to use exact 
file window mapping with an upper limit of the volume 
window size. The original module checksum is 70061(8) 
and the INWIN.POB file checksum is 16421(8). 

.TITLE INWIN 
.IDENT /M0226/ 

• RWS015 - USE VOLUME DEFAULT AS UPPER LIMIT TO 

TRY FULL MAPPING. 
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.PSECT INWIN 
.PURE. = . 

. = .PURE.+24 

MOVB V.WISZ(R4>,R1 ;GET THE VOLUME DE¬ 

FAULT 

NOP ; FALL INTO FULL LOGIC 

. = .PURE.+52 
CALL PATOOl 

.PSECT PATOOl 

.PURE. = . 

PATOOl: MOV R1,R3 

AL POINTER SIZE 
BGT 10$ 

LIMIT 

MOV <<512.-W.RTRV>/6.>,R3 

SIZE 

10$: RETURN 

.END 


13,7 PMD Correction 


The following PAT correction file fixes the problem 
in PMD with 4KW APR7 windows. The orginal object file 
checksum is 37060(8) and the PMD.POB file checksum is 
4122(8) . 

.TITLE PMD 
.IDENT /07.2/ 

• MODIFICATION: 

• RWS012 -- FIX DUMMPING OF 4KW APR7 WINDOW 


.PSECT 


. = .BLK.+1776 
NOP 

.END 


;COPY RETRIEV- 
; IF GT - USE AS UPPER 
;SET MAXIMUM RETRIEVAL 
; AND CONTINUE 
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13.8 TSHOW Correction 


The following is a corrected version of the 
TSHOW.COR file on the Autopatch B kit. 

C23,10:TSH0W.MAC;2/AU/-BF=C23,lODTSHOW.MAC;1 

- 2,2 

.IDENT /Ol.Ol/ 

- 20,20 

; LHS032 CORRECTED SHO ACC SYNTAX 

% 

-36,37,/;LHS032/ 

.IF DF R$$MPL 

OR <GNITNUOCCA BST=B1> 

OR. <‘CLQ BST=B2> 

.IFF 

OR <‘CLQ BST=B2> 

.ENDC 

-55,71,/;LHS032/ 

.IF DF R$$MPL 
GNITNUOCCA: 

AND <<‘SHO ACC >> <MAP=1 OPT=T> 

END 

.ENDC 

/ 
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